Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's

From: [email-masked]
Date: Tue, 9 Aug 2005 16:12:16 +0300

It seems to me that looking at marshalling DOM Events and sending them over the wire is a good start. With this in mind we can create a protocol that offers the *primitives* that enables XML DOM synchronisation. The actual synchronisation is a different matter and we already see several possibilities for doing so, some of them extremely simple and some more complicated depending on the environment that is targeted.

In RUI/WiDeX context things are easy: the UI server "owns" the DOM object, UI client is stateless, the nature of the updates is different on UI server and UI client, update collisions are unlikely (for a well behaving application).

Looking at what kind of deliverables this group can produce, I see the following:
1. Requirements document
2. Protocol providing the synchronisation primitives
3. UI remoting framework describing how to use the protocol in this context and how to interact with other sub-systems (i.e. service discovery).

Splitting the work in this way we solve the UI remoting problem in a generic way by enabling the possibility to reuse the protocol for other environments. Additionally, we will be able to deliver something in a fairly short time with low complexity and also build a solid basis for further development.

I also feel that we need to provide the right tool for a particular environment and in this case by having a one-size-fits-all "generic" synchronisation protocol will add unnecessary burden on some simple devices.

Cheers,
Vlad

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Eric Burger
> Sent: 09 August, 2005 14:11
> To: Dave Raggett
> Cc: [email-masked]
> Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's
> 
> 
> Sounds good.  However, I guess I get to play on both sides of this
> fence.
> 
> Namely, while it sounds nice to say "the DOM owns the DOM", that can
> introduce serious complexities in the protocol.  A few of these
> complexities are tractable, others are not.
> 
> The one that immediately comes to mind as not being (cleanly) 
> tractable
> is what to do in the case of network partitioning.  In the case of a
> network partition, both entities may attempt to update or propagate
> events in the DOM tree at the same node.  When the network is 
> restored,
> how does one reconcile conflicting updates?  It is easy if 
> the "server"
> (in Vlad's terminology) owns the tree.  Updates only ever get sent out
> to the "client".
> 
> Given the user interface in the rmt model simply manipulates 
> the DOM, I
> could envision what I think you're saying.  Namely, the client gets
> exclusive access to parts of the tree (representing the user input)
> while the server gets exclusive access to the rest of the tree.
> 
> Looking at the word choice above, one could make things 
> "easy" and have
> a definite "preferred direction", i.e., from server to client.  Or, we
> can make things abstract and have wider applicability, have no concept
> of a preferred participant in the exchange, but have a slightly more
> complex protocol.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Dave Raggett
> Sent: Monday, August 08, 2005 11:08 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Like Eric, I believe that scoping a protocol to a well characterised 
> problem with broad appeal is important to achieving a successful 
> outcome in terms of reaching closure on the protocol and having it
> widely implemented and exploited.  XML is being increasingly used
> for applications for both the user interface and the associated data 
> models. XHTML, SVG, SMIL, XForms, XAML, and XUL are examples of this
> trend. The combination of XML and scripting is also very popular, 
> whether on cell phones, desktops or on servers. A protocol for 
> synchronizing XML DOM's has the potential to widely useful.
> 
> With regards to your specific points:
> 
> First: XML is suitable for open platform independent applications,
> as has been shown by the very wide range of devices and
> operating systems that XML applications have been deployed on.
> 
> Second: a stateless protocol can be used to synchronize XML DOM's
> as the state is held in the DOM. For many cases, it is sufficient
> to replicate DOM events from one system to the other, along with
> DOM mutations. The capture/bubble model introduces a little extra
> complexity, but is bounded by the semantics of DOM Events. A simple
> access rights model will allow a DOM Exception to be raised when
> trying to mutate a node you don't have the rights to do so.
> 
> What about the assumptions I proposed?
> 
>    a) the fact that the DOM is distributed can be hidden from
>       the code (markup interpreter or script) operating on the DOM
> 
>    b) the synchronization protocol doesn't need to be aware of
>       the semantics of the markup that is being synchronized.
> 
>    c) the synchronization occurs at a fairly loose level that
>       allows for a simple approach to propagating changes.
> 
>    d) latency considerations are important and the user interface
>       should not block on waiting for replies from other devices
> 
> To which I would add:
> 
>    e) the state is held in the DOM allowing the synchronization
>       protocol itself to be stateless
> 
> - -- 
>   Dave Raggett <[email-masked]>  W3C lead for multimodal interaction
>   http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFC93U5b3AdEmxAsUsRAoymAKCL5JSCcPCQ9y96jfgYWg6tWY5bBgCfXz97
> p5KghIRUbhRpuIOVtL9Do6E=
> =S7zW
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> REMOTEUI mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/remoteui
> 
> _______________________________________________
> REMOTEUI mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/remoteui
> 

_______________________________________________
REMOTEUI mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/remoteui

---

From: Dave Raggett <[email-masked]>
Date: Wed, 10 Aug 2005 13:09:54 +0100 (BST)

I think we have a rough agreement on the idea of marshalling DOM 
events as XML messages, and on representing DOM updates in XML with 
XPath as a means to identify where the updates apply. I perceive 
open issues such as support for the capture/bubble model of DOM 
events, and whether only the server can do DOM updates, or whether 
this can be generalised in a lightweight way. These merit further
study on the pros and cons. I think we are also in agreement that
the means to establish sessions and support for device coordination
should be factored out and not addressed by the remote UI protocol.

When it comes to motivation, I believe that we are in agreement on 
enabling remote user interfaces on a range of devices from simple to 
complex. However, that is a little too abstract on its own, and I
recommend that we ground the charter in the context of working going
on elsewhere, including that at W3C.

An XML-based protocol to convey DOM events and DOM updates looks 
likely to be of high value to implementing the W3C Multimodal 
Interaction architecture[1], to enabling dynamic adaptation to the 
delivery context[2], and more generally as a means to enable the 
refactoring of device independent markup[3] between the client and 
server for thin clients, where a web page "runs" on the server with 
small pieces dispatched to the thin client and kept in sync with the 
server via the remote UI protocol.

I would be happy to collaborate on drafting a proposed charter that 
covers requirements and an associated protocol for DOM events and 
updates. The charter should mention open issues and ground the work 
in terms of uses cases and the relation to other work, including 
that at W3C. We should also explain why session establishment is out 
of scope and how existing approaches can be used to address it. For 
some context on that, see my W3C presentation on the Ubiquitous 
Web[4].

  [1] http://www.w3.org/TR/mmi-arch/
  [2] http://www.w3.org/TR/DPF/
  [3] http://www.w3.org/2001/di/
  [4] ttp://www.w3.org/2005/Talks/0621-dsr-ubiweb/

Is this adequate as a basis for moving forward?

- --