MobWrite on Comet

[Sathvik Ponangi]

Has anyone tried to port MobWrite to a comet based system? Maybe like the AppEngine Channels or a Tornado like server?

If not, why? Is the current ajax-long-polling better than a server-side push?

[Mikey]

A continuous connection is not required and has shown to damage server
performance (you block a connection to a server, and they can only
hold so many) (though this wastage may not ever apply to mobwrite in
typical actions)

The performance/latency ratio is a fine balance and is better
controlled by the clients (polling) instead of the server (pushing).

Why has it not been done?

Mobwrites protocol can be implemented (and simplified) into HTTP
requests. Errors (conflicts) are completely moved to the clients.

PATCH is now a standard verb, but i disagree with it. A PUT with
Content-Encoding: google-dmp; base=<revisionTag> feels alot better to
me.

A generic plugin to support google-diff-match-patch as a Content-
Encoding into Apache would allow lock-free editing to the entire web.

The question becomes, is there a need for it? The whole system can be
emulated with PUTs and GETs, Delta's are just a form of compression,
and the internet has become very fast and text files are typically
very small.

Mike Brown

[Brian Slesinsky]

On Friday, December 30, 2011 5:12:36 PM UTC-5, Mikey wrote:

A continuous connection is not required and has shown to damage server

performance.

However, we won't know for sure until someone tries it, and I don't think it has ever been tried with mobwrite. 

If you're interested, I recommend implementing it and seeing if it helps. My idea is to use an App Engine channel to send a "wake up" signal causing the client to poll the server. That way, there is minimal change to the protocol, we can eliminate a lot of unnecessary polls, and we should get better latency when someone makes a change after the document has been sitting idle for a while. (It might still make sense to do polls immediately when the document is changing rapidly.)

- Brian