RE: [Widex] Proposed rewording for Framework draft

[<[e-mail]>]

Hi,

Here is the proposed reworded text, following Figure 2, considering the
discussion in this thread:

   The Widex Framework needs a mechanism by which the Widex Renderer
   determines which events have a remote scope and therefore need to be
   serialized and forwarded to the Widex Server.  The determination of
   which events have a remote scope could be achieved in one of three
   ways:

   o  prior agreement between the Widex Renderer and Widex Server
   o  a list of events passed during session establishment
   o  the Widex Server could direct the Widex Renderer to add and remove
      event listeners during the session

   The Widex Framework enables remote event listeners to be dynamically
   attached to DOM nodes during the session using WO.Selector messages
   as described in Section 4.3.  Local event listeners that are not
   forwarded to the Widex Server may be dynamically attached through
   WO.Update messages as described in Section 4.1, and which update the
   DOM tree that is interpreted by the Widex Renderer.

   With the Model-View-Controller design pattern, updates to the
   (virtual) DOM tree held by the Widex Server are reflected as
   WO.Update messages that in turn result in the Widex Renderer updating
   its copy of the DOM tree to match the changes made by the Widex
   Server.  A similar process occurs when the Widex Server adds or
   removes event listeners, where these changes are mediated by
   WO.Selector messages.

   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.

   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, that is, an in-memory XML DOM tree, as this is an
   implementation dependent design choice.

Please check if the above text is in line which what was discussed in
the thread... I may have missed something.

I'll post an updated version of the draft on Monday, before the deadline
for IETF66. Wait for your comments...

Vlad

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