RE: [Widex] Proposed rewording for Framework draft
<Vlad.Stirbu@nokia.com> Sat, 17 June 2006 15:11 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrcSG-0007ni-0o; Sat, 17 Jun 2006 11:11:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrcSF-0007nZ-3V for widex@ietf.org; Sat, 17 Jun 2006 11:11:19 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrZor-00020o-PN for widex@ietf.org; Sat, 17 Jun 2006 08:22:29 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrZhU-0003Hm-7D for widex@ietf.org; Sat, 17 Jun 2006 08:14:52 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5HCEmcg018175; Sat, 17 Jun 2006 15:14:50 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jun 2006 15:14:33 +0300
Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jun 2006 15:14:33 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Sat, 17 Jun 2006 15:14:27 +0300
Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B023988EC@trebe101.NOE.Nokia.com>
In-Reply-To: <000001c6919e$9ce06610$1e02a8c0@martsbs.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Widex] Proposed rewording for Framework draft
Thread-Index: AcaRX/S0Os7dkDeMQ2ienBBi+DJLuwAPJqkAABp/cLA=
From: Vlad.Stirbu@nokia.com
To: jyu@openxup.org, dsr@w3.org
X-OriginalArrivalTime: 17 Jun 2006 12:14:33.0136 (UTC) FILETIME=[97885B00:01C69207]
X-Spam-Score: -1.9 (-)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org
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 Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex
- [Widex] Proposed rewording for Framework draft Dave Raggett
- Re: [Widex] Proposed rewording for Framework draft Dave Raggett
- RE: [Widex] Proposed rewording for Framework draft Jin Yu
- RE: [Widex] Proposed rewording for Framework draft Dave Raggett
- RE: [Widex] Proposed rewording for Framework draft Jin Yu
- RE: [Widex] Proposed rewording for Framework draft Dave Raggett
- RE: [Widex] Proposed rewording for Framework draft Vlad.Stirbu
- RE: [Widex] Proposed rewording for Framework draft Jin Yu
- RE: [Widex] Proposed rewording for Framework draft Dave Raggett
- RE: [Widex] Proposed rewording for Framework draft Jin Yu
- RE: [Widex] Proposed rewording for Framework draft Vlad.Stirbu
- RE: [Widex] Proposed rewording for Framework draft Jin Yu
- RE: [Widex] Proposed rewording for Framework draft Vlad.Stirbu
- RE: [Widex] Proposed rewording for Framework draft Jin Yu
- RE: [Widex] Proposed rewording for Framework draft Dave Raggett
- RE: [Widex] Proposed rewording for Framework draft Jin Yu
- RE: [Widex] Proposed rewording for Framework draft Dave Raggett
- Re: [Widex] Proposed rewording for Framework draft Rosfran Lins Borges
- Re: [Widex] Proposed rewording for Framework draft Dave Raggett
- Re: [Widex] Proposed rewording for Framework draft Rosfran Lins Borges
- Re: [Widex] Proposed rewording for Framework draft Dave Raggett
- Re: [Widex] Proposed rewording for Framework draft Rosfran Lins Borges