[Standards] shared XML editing update

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 6 23:05:55 UTC 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