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

From: "Eric Burger" <[email-masked]>
Date: Tue, 9 Aug 2005 07:11:09 -0400

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

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)

_______________________________________________
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: Tue, 9 Aug 2005 15:54:21 +0100 (BST)

On Tue, 9 Aug 2005, Eric Burger wrote:

> 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.

In most practical cases there is indeed a preferred direction, and 
this is why I proposed the notion of an "owner". In the simplest 
case, all user interface events are passed to the application which 
updates the user interface accordingly. With a clean separation 
between presentation, data and logic, not all user interaction needs 
to be exposed to the server. For instance, pointer movements and 
individual keystrokes. The server is only interested in higher level 
events, such as in changes to the data model, or a change in the 
input focus.

In the W3C Multimodal Interaction Architecture, such higher level 
events are passed through an interaction manager that coordinates 
the modality components and the shared data model. In terms of the 
model/view/controller paradigm, there can be multiple views, but 
communication between these can only take place via the controller.
This fits in with Vlad's ideas in that the views raise events while
the controller updates the views.

The asymmetry allows for a simple protocol. We don't need to go
as far as a full transactional model with commits and roll-backs.
The controller/interaction manager is responsible for reconciling
what would otherwise be conflicting inputs, whether they are
events or updates.

A client needs to know which DOM events need to be passed to the 
controller. This could be set up via a subscription mechanism or
via appropriate metadata. Similarly DOM updates may be possible
on some nodes but not on others and it depends on whether the
markup is internal to the modality component or shared.

If clients are allowed to update the shared DOM, then the proposed 
changes could be passed to the owner (controller) which then 
distributes the changes to the clients. This would mean that DOM 
updates are no longer synchronous in the sense that when a DOM 
method returns, you can't be certain that the change has been 
applied. This would allow a series of DOM calls to be serialized
and streamed to the owner. In response, the owner could accept the 
changes and pass them on to the clients to be applied, or could 
raise an error event on the client that requested the change. This 
approach ensure that the clients are kept in sync with the server
at the cost of introducing a delay into applying changes, and the
use of an event rather than an exception to signal a problem.

Applications need to be designed appropriately if they are to
operate when the network is temporarily unavailable. In W3C work
on XForms, we have thought about the possibility of being able
to suspend an application and to later resume it. Some applications
may be able to continue to operate but with reduced functionality.
The application may support a reconciliation mechanism when
connectivity is resumed. The question is what support is needed
from the protocol. The answer may be very little if the desired
behavior is supported at the application level.

- --