Efficient storage/retrieval method for replayable comet style applications (Google Wave, Etherpad)

Question

I am considering a web application that would have the same kind of multi user, automatic saving, infinite undo / replay capabilities that you see in Google Wave and Etherpad (albeit on a drastically smaller scale and userbase).

Before I go away and reinvent the wheel, is this something that has already been addressed as either a piece of technology or library, or even just a design pattern.

I know this isn't necessarily the best Stack Overflow question as there is probably not a "right" answer, but my Google-fu has failed me and I'd just like a reading list!

Ordinarily I would be developing under python/django but this is not a firm requirement just a preference :)

Answer 1

Sounds like a real technologoical club sandwich:

• Web page serving and user and session management server code in Server(s)

• OLTP and Comet Instant Messaging server code in Server(s)

• Version control conflict resolution code in Server

• In-RAM version control database in Client internals

• Version control conflict resolution code in Client (operates in batches on incoming bytes to increase responsiveness - client platform is single-threaded!)

• Comet Instant Messaging client code in Client internals (operates in batches on incoming bytes to increase responsiveness - client platform is single-threaded!)

• Text measurement in Client GUI

• (optional) Custom bitmap font for browsers with poorly understood font metrics

• 2D animation code in Client GUI (operates in batches on to-paint list to increase responsiveness - client platform is single-threaded!)

• Web user session management server code in Client pages

The main design concerns will be flexibility of network usage model to support continued operation in the face of unhelpful proxy servers and connection or bandwidth limitation needs. You probably need to be able to switch easily between quite a varied suite of Comet signalling strategies and timeout ranges, to experiment with, and to allow the app to easily grow as any limitations and problems with Comet in the field reduce.

I expect the main implementation concern will be achieving the shortest possible sequence of events between the GUI accepting and confirming caret position changes or receiving edits from (the) Comet (layer) and text entry changes.