On Jan 30, 2008 1:24 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Joonas Govenius has been quietly but steadily working on his shared XML > editing protocol, which can serve as the foundation for whiteboarding, > XHTML authoring, editing of collaborative data objects (XEP-0204), etc.
Agree with the fact that we need some common ground. As I've said in the fosdem ML one more interesting application may be "XMPP widgets", i.e. small UI snippets that can modified by remote services. The main aim for these snippets is to allow pushing the UI for some applications that require special support in the client, such as a pubsub based news reader, or microblogging. Why waiting for client developers implementing them, when it could be possible to have all the application contained in a widget displayed when subscribing to a given jid? That's the same model that made the success of the web: don't require special support, new software installations, just click and use it. I don't any reason for not pursuing it in xmpp ;) > He and I chatted the other day and I suggested that we could use Jingle > as the negotiation and session management layer for shared XML editing, > rather than the homegrown technology he had defined. He agreed that it > would be interesting to investigate this, for the sake of code reuse and > consistency across XMPP protocol extensions. Ok with jingle, I don't see any particular issue (though I don't master the full jingle specification yet...). From what I'm getting of the problem at present, I'd like just to have some flexibility of the transport. SXE shouldn't be the only transport allowed for state synchronization, since it should be possible to: - use different formats than xml, e.g json for easy integration with web frameworks, where I see the first applications of this protocol - exchange whole dom chunks and replace or add a subtree, since it's much more space efficient than sending instructions with the changes to be applied; moreover dom manipulation libs already work in this way. SXE may oblige doing twice the work, serializing the changes into processing instructions and applying them (it's good instead when you need to remember a history such as in whiteboarding or shared editing). Another thing I'd like see for widgets, and that's not necessary for whiteboarding and shared editing, is the possibility to automatically start document synchronizations with presence or pubsub events. Think for example a news reader based on a widget: the client should be able to receive all updates when going online (with a particular resource), without explicetely restarting a new session, and the service should be able to exploit pubsub for publishing new items, without keeping track of all client subscriptions. > It still requires some work, but I think it is showing real promise. I'll be very happy to join and help if you think that these suggestions are worth further work on the xep. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
