RE: [Widex] Proposed rewording for Framework draft

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

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

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex