[Standards] shared XML editing update
Peter Saint-Andre
stpeter at stpeter.im
Wed Feb 6 17:05:55 CST 2008
Fabio Forno wrote:
> 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:
Right. We might want something different from SXE for state sync. I've
heard from one of the authors of XEP-0204 (Collaborative Data Objects)
that their needs are slightly different from SXE, too.
> - 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).
I get the sense that you want something like REX:
http://www.w3.org/TR/rex/
Unfortunately they had to stop working on that because of patent problems:
http://www.w3.org/2006/rex-pag/rex-pag-report.html
> 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.
Yes, that kind of approach might make more sense in a MUC room or at a
dedicated whiteboarding server. It would be good to build that in.
>> 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.
Great, thanks!
Peter
--
Peter Saint-Andre
https://stpeter.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080206/20e05518/attachment.bin
More information about the Standards
mailing list