• Clients update to changes to the state in near real-time


• Any client can modify the state, causing all others to update


• Conflicts arising from multiple incompatible updates to the same data at the same time are resolved in such a way that the user can understand (and, if necessary, amend) them


• Clients can easily join and leave the group at run time


• Low enough traffic to not flood the network


• Clients can't rely on external services being present on the machine - they need to be able to launch them if they need them

.meic | fruuti

That's probably not a bad idea.

Rowan, can you give us some real world context?

1. There's no requirement for version control (beyond whatever's necessary for conflict resolution, which I imagine is minimal).


2. They're not really set up to disseminate changes to a bunch of peers, AFAIK


3. The ideal solution would keep it all in memory for rapid access


4. It'd also be easy to integrate into an application (of course it'd be possible to do that with Git, etc, but it's not what the designers had in mind)

.meic | fruuti

Can't really give you context, no, as it's just a hypothetical.

How about as the basis for a system for booking meeting rooms in a large office building? I realise there are solutions for this already, but just as an example. Lots of users need to read and manipulate the data at the same time, and changes need to propagate out to all the users quickly.

.meic | fruuti

Yeah, I guess... But, saying it's "like Wave" makes it sound cutting edge, or something. I don't think it's as exotic as all that, really. I mean, you could kinda say the same about IRC (which just has a conflict resolution system of "meh").

I'm sure there are tonnes of applications that do this sort of thing, and I guess most of them roll their own master/slave thing.

.meic | fruuti

Sure they have! Obvious examples are IM clients, but that sort of stuff is everywhere now (e.g. presence stuff in Steam). Even Explorer will magically update itself if you're viewing a remote folder whose content changes.

Ta for the OT link - already had it open in a browser for later reading.

.meic | fruuti

I've not used the word collaboration (as I suspect it has some specific technical meaning). IM clients do have shared/synchronised state, though - the presence data is a better example than the actually chat, as it's not append-only. Consider a user logged in to the same account on multiple clients and they change their name on one; all the clients can change that state, and as soon as one does, the change propagates to the others.

I don't understand how to answer your second question. I have no actual need to solve this problem, I'm merely interested.

.meic | fruuti

Okay, so that operation transformation thing looks like it's just a jargon-heavy way of consistently serialising the kind of commands I suggested in my first post.

I guess that's just the way everyone tackles this sort of thing, 'cos it's simpler, and there's no real reason not to at this scale. Ho hum.

.meic | fruuti

Along the lines of AMQP, take a look at www.rabbitmq.com It's a doddle to set up, lightning quick (we regularly run at ~80,000 messages/sec between Europe and the US over the public internet), will run in RAM or on disk and supports quite a few message distribution models, including allowing an ad-hoc number of consumers to connect and receive messages - so each client would just register its own queue update consumer when it was fired up, and when an update is made in a client it could be published out to all.

It's worth doing the 6 tutorials so you can see just what it can do - a solution may present itself to you.