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.
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.
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.
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.
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.
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.