AtomizeJS: A library for writing distributed programs in the browser

http://atomizejs.github.com/

by ntoshev • 14 years ago

49 11 14 years ago

atomizejs.github.com

Cool idea! I hope it never gets popular at the same time.

radarsat12• 14 years ago

This sounds very impressive and interesting. Synchronized distributed applications without deadlocks, while worrying only about client-side code? Sounds amazing, I'll have to play with it.

methoddk• 14 years ago

Same here, I'll have to put something together with this later.

msackman3• 14 years ago

I've just pushed new versions of the client and server which solve a couple of bugs. Please let me know how you get on if you have a chance to try out this stuff. Would be great to get some feedback.

radarsat12• 14 years ago

Just out of curiosity, how much is it tied to Node? I mean, I imagine the server side could be implemented in other languages, but how much are you leveraging the fact that Javascript is used on both server and client? Just wondering because I'd be interested in running this with a Python back-end.

msackman3• 14 years ago

The protocol between client and server is dead simple, and the server is currently about 400 lines of code. The only reason the server is still in nodejs is because it's quite neat to be able to write transactions on the server-side too and by being in JS, I can just use the same client code as in the browser to do that, with very few changes. Writing just the txn engine in other languages would be very simple too. Next week I'm hoping to write some documentation for the protocol. But it's really just abstract addresses and version numbers and such. No rocket science at all - especially given that Node is single-threaded!

DanWaterworth2• 14 years ago

Maybe I'm missing something, but how do you ensure that nefarious clients don't screw up your state?

msackman3• 14 years ago

Currently, you can't, so you're not missing anything. :) But I'm currently working on the necessary hooks so that any security model you want can be enforced by the server.

hengli• 14 years ago

But if we're doing that will that really be that different from current client-server implementations?

DanWaterworth2• 14 years ago

I have worked on projects that occupy this space. I tend to think that it's ok for the client to have arbitrary read access, but for writes it's a better idea for the client to generate events that are then approved and applied by the/a server. The reason for this is that it's much easier to approve high level events than low-level change-sets.

AtomizeJS: A library for writing distributed programs in the browser

Related Stories