RE: [Widex] Proposed rewording for Framework draft

[Dave Raggett <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 15 Jun 2006, Jin Yu wrote:

>>> We may also want to say something about the behavior of multiple 
>>> event listeners (a mix of local and remote listeners) for the 
>>> same event. For example, in XUP, if a local listener can fully 
>>> handle an event locally, it can prevent a remote listener from 
>>> being called.
>>
>> I think that comes down to the processing model for events. In the
>> case of DOM events, there is provision to stop propagation and to
>> prevent the default handler from being invoked. It is therefore a
>> matter of where the remote event listener is attached. A local
>> handler could then prevent the remote event listener from being
>> invoked. The otherway round is more complicated. The stub used
>> in the Widex Renderer could stop further propagation, but there
>> would be undue latency to allow the corresponding handler in the
>> Widex Server to be able to do so.
>>
>> We could include some text on this in the Widex Framework draft,
>> but is it really necessary? It seems like being at a different
>> level of detail.
>
> I think it would be nice to have some text explaining how remote 
> events and listeners relate to (or work with) DOM's event model. 
> Something along the line you wrote above seems to be very 
> reasonable.

So how about:

  With the DOM Event model it is possible to attach multiple
  event listeners for the same event. The DOM event model
  defines an ordering in which the listeners are invoked, and
  provides a means to stop further propagation of the event,
  and to prevent the default event handler from being invoked.
  In the case of a mix of local and remote event listeners,
  depending on where they are attached, a local event listener
  could stop further propagation and thereby prevent the remote
  event listener from being invoked. The other way around is
  more complicated. The stub used by the Widex Renderer for
  remote event listeners could itself stop further propagation,
  but there would be undue latency incurred if this was to be
  done by the corresponding event handler in the Widex Server.

Which leaves open the possibility for WO.Selector messages
to specify whether or not the event listener stub used in
the Widex Renderer should call the preventDefault method or
the stopPropagation method on DOM events.

>>>>   In a little more detail, changes made by the Widex Server
>>>>   to the XML DOM for the View, result in DOM events, e.g.
>>>>   DOM Mutation events. The Widex Framework in the server
>>>>   (as shown in Figure 1) can listen for these events to
>>>>   generate the corresponding Widex messages. The Widex
>>>>   Framework in the Renderer interprets these messages to
>>>>   reflect the changes to its copy of the XML DOM for the
>>>>   View. Note that the Widex messages are independent of
>>>>   whether the Widex Server has an explicit or a virtual
>>>>   View.
>>>
>>> I think this is more like an implementation suggestion (i.e.
>>> using DOM mutation events on the server side). There are other
>>> implementation techniques for the server to trace and serialize
>>> the UI updates. For example, in the OpenXUP server, we don't use
>>> DOM events at all for performance reasons. The server has a UI
>>> tracker, which tracks every API calls to the UI tree; and at the
>>> end of the request processing, the content of the UI tracker is
>>> serialized into UI updates and sent to the client.
>>
>> Agreed, but what should we say if anything in the Widex Framework 
>> draft?
>
> I think we could just rephrase your paragraph a bit, implying it's 
> a possible implementation approach. Also, I don't quite understand 
> the last sentence - what do you mean by "explicit view"? My 
> understanding is that the server's view is always virtual, whereas 
> the renderer keeps the concrete (or physical) view.

It is up to the implementation whether or not the Widex Server
has a virtual or explicit XML DOM for the View. However, that
has no effect on the Widex Protocol.

So how about:

  In an implementation where the Widex Server maintains
  an explicit XML DOM for the View, changes made by the
  Widex Server to this View result in DOM events, e.g.
  DOM Mutation events. The Widex Framework in the server
  (as shown in Figure 1) can listen for these events to
  generate the corresponding Widex messages. The Widex
  Framework in the Renderer interprets these messages to
  reflect the changes to its copy of the XML DOM for the
  View. Note that the Widex messages are independent of
  whether the Widex Server has an explicit or a virtual
  View.

Regards,

  Dave Raggett <[e-mail]>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett [phone] (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEkm+ib3AdEmxAsUsRAiM1AKC2oI1nxVpz8awk7GTG7gM1JCxsygCg0y7n
sjnjZ91kGQn6mBmjzXY6N8U=
=N5R9
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/widex