From remoteui-bounces@lists.ietf.org Thu Aug 04 13:58:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jyz-0003RN-1b; Thu, 04 Aug 2005 13:58:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jyx-0003RI-Cw for remoteui@megatron.ietf.org; Thu, 04 Aug 2005 13:58:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27253 for ; Thu, 4 Aug 2005 13:58:14 -0400 (EDT) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0kVr-0002sD-Cs for remoteui@ietf.org; Thu, 04 Aug 2005 14:32:17 -0400 Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 1489E4F375 for ; Thu, 4 Aug 2005 13:58:08 -0400 (EDT) Date: Thu, 4 Aug 2005 18:58:04 +0100 (BST) From: Dave Raggett X-X-Sender: dsr@holly To: remoteui@ietf.org Message-ID: X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Subject: [REMOTEUI] scoping to synchronizing distributed XML DOM's X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a follow up to the talk I presented at the Remote UI BoF on 2nd August, see: http://www.w3.org/2005/Talks/0802-dsr-ui/ I am assuming that everyone on this list is familiar with the benefits of using markup for representing user interfaces and the importance of a clean separation between presentation, data and control for developing applications. XML has been applied to both the user interface and to the data. and as such it makes sense to generalize the synchronization mechanism proposed in the BoF to cover both cases. In short, I believe that it would be valuable to develop protocol support for synchronising distributed XML DOM's. This would complement existing W3C work on multimodal interaction and device independence. For MMI, it would support the synchronization of shared data models as well as distributed multimodal user interfaces. For DI, it would support the representation of device capabilities and configuration as DOM nodes when these nodes reflect properties of remote devices, e.g. remaining paper supplies in a printer, and also enable thin clients to take part in complex web applications through a re-factoring of the markup between devices and servers. As was discussed in the BoF, it makes sense to factor out work on establishing the session context and other aspects related to device coordination, and to instead focus on just what is needed to synchronize distributed XML DOM's. The basic scenario is where two devices hold copies of the same XML document, which could represent the user interface or a shared data model. DOM events can be raised in either device and need to be propagated to the other device. Similarly changes to the XML in one device needs to be propagated to the other device. The fact that the DOM is distributed is hidden from the code that is manipulating the DOM. This code could be a markup language interpreter or scripting engine. This is summarised in slide form at: http://www.w3.org/2005/Talks/0802-dsr-ui/#[12] The DOM is defined by a suite of W3C Recommendations that specify platform and language neutral interfaces in IDL with bindings to EMAScript and other languages. A DOM document is a hierarchy of DOM Nodes which occur as elements, attributes, strings and other derived types. The DOM Node interface provides the means to traverse the node hierarchy and to mutate it through the addition and removal of nodes. There is also a rich model of events with the means to handle events prior to their delivery to the target node, or afterwards, in a capture/buble model. For more details see: http://www.w3.org/DOM/ DOM Events are formally defined in IDL and should thus be amenable to marshalling as messages in a message exchange protocol. More recently, W3C has been looking at extending the DOM to support interpreted user input expressed in XML in application dependent markup and annotated with annotations for such things as timestamps, confidence scores, input modality, alternative recognition hypotheses and other information of interest, see: http://www.w3.org/TR/emma/ EMMA is expected to progress to Last Call Working Draft status within a few weeks from now, and is intended for a wide variety of uses, e.g. speech recognition, pen gestures, interpreted keystrokes, etc. A protocol to support the distribution of DOM events between synchronized DOM's will need to take the DOM event model into account. This includes such things as how to identify the event target (a node in the node hierarchy), and the means for event listeners to stop propagation in either the capture or bubble phases. This is simple when all of the event listeners are in one device, but when some are on one device and some are on another, things get a little more complicated. For DOM updates, I would like to alert people to the work on "XUpdate" done several years ago. See: http://xmldb-org.sourceforge.net/xupdate/ XUpdate serializes DOM Mutation operations as XML messages, and uses XPath to identify where in the node hierarchy a particular operation should be applied. The use of XML to serialize DOM operations makes for a declarative representation and can be straightforwardly applied to IDL datatypes. The semantics are well defined compared with shipping program fragments and this should also simplify security considerations. In applications involving multiple devices, or multiple modality components, such as proposed in the W3C Multimodal Interaction Architecture, there may be more than two instances of the DOM requiring synchronization. Different parts of the DOM tree may be "owned" by different devices. It make sense to consider what kind of access rights model is needed. One possibility is for annotating nodes as being unmutable, or mutable only by the owner, or mutable by all participants. A more complicated approach would be to implement some kind of transactional model with commits and roll-backs. This is probably overkill for the intended purpose of supporting remote user interfaces, but it may be possible for the application to support something like this at a higher level without burdening the DOM synchronization protocol itself. In addition to incremental changes, it will also be necessary to enable to replacement of an entire DOM tree or subtree by another. This is clearly important when starting up. Although session initiation is out of scope for the synchronisation primitives, it is worth working through a simple scenario to provide a fuller context. One possibility is for a client device to use SIP to establish an application session. Once a control path has been established to a server, the server can then send control messages to the client to load the user interface and shared data model. synchronization messages can then be exchanged as the user interacts with the remote application. Finally control messages outside of the scope of the synchronization protocol can be used to terminate the application and release resources. Some assumptions include: 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 - -- Dave Raggett W3C lead for multimodal interaction http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC8lcxb3AdEmxAsUsRArmwAKDMow2EwUgKitJuIk5i0TaOevUT6wCgqmK9 mQF+t4jhwA2xQAbfplxw8e4= =r8yo -----END PGP SIGNATURE----- _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Sun Aug 07 16:50:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1s60-0000VC-F2; Sun, 07 Aug 2005 16:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1s5y-0000V1-FA for remoteui@megatron.ietf.org; Sun, 07 Aug 2005 16:50:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27037 for ; Sun, 7 Aug 2005 16:50:08 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1sdX-0001aQ-H6 for remoteui@ietf.org; Sun, 07 Aug 2005 17:24:51 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j77KnYxj014224 for ; Sun, 7 Aug 2005 16:49:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's Date: Sun, 7 Aug 2005 16:49:33 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647A06132@ATLANTIS.Brooktrout.com> Thread-Topic: [REMOTEUI] scoping to synchronizing distributed XML DOM's Thread-Index: AcWZHjCcXwCKLUYsSHeytnIIKrW+gwCMxnmg From: "Eric Burger" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org I would also like to highlight some of Dave's points below. Namely, the protocol must take into account the DOM event model. The reason I consider this important is because XML DOM synchronization is a well characterized problem space. It puts on a number of important AND USEFUL constraints on the solution space for the synchronization protocol. These constraints give us the opportunity to create an efficient, usable protocol. Were we to focus on an abstract synchronization protocol, I fear we would (1) never finish and (2) if we did finish, no one would be able to implement it. -----Original Message----- From: remoteui-bounces@lists.ietf.org [mailto:remoteui-bounces@lists.ietf.org] On Behalf Of Dave Raggett Sent: Thursday, August 04, 2005 1:58 PM To: remoteui@ietf.org Subject: [REMOTEUI] scoping to synchronizing distributed XML DOM's -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a follow up to the talk I presented at the Remote UI BoF on 2nd August, see: http://www.w3.org/2005/Talks/0802-dsr-ui/ I am assuming that everyone on this list is familiar with the benefits of using markup for representing user interfaces and the importance of a clean separation between presentation, data and control for developing applications. XML has been applied to both the user interface and to the data. and as such it makes sense to generalize the synchronization mechanism proposed in the BoF to cover both cases. In short, I believe that it would be valuable to develop protocol support for synchronising distributed XML DOM's. This would complement existing W3C work on multimodal interaction and device=20 independence. For MMI, it would support the synchronization of=20 shared data models as well as distributed multimodal user=20 interfaces. For DI, it would support the representation of device=20 capabilities and configuration as DOM nodes when these nodes reflect=20 properties of remote devices, e.g. remaining paper supplies in a=20 printer, and also enable thin clients to take part in complex web=20 applications through a re-factoring of the markup between devices=20 and servers. As was discussed in the BoF, it makes sense to factor out work on establishing the session context and other aspects related to device coordination, and to instead focus on just what is needed to synchronize distributed XML DOM's. The basic scenario is where two devices hold copies of the same XML document, which could represent the user interface or a shared data model. DOM events can be raised in either device and need to be propagated to the other device. Similarly changes to the XML in one device needs to be propagated to the other device. The fact that the DOM is distributed is hidden from the code that is manipulating the DOM. This code could be a markup language interpreter or scripting engine. This is summarised in slide form at: http://www.w3.org/2005/Talks/0802-dsr-ui/#[12] The DOM is defined by a suite of W3C Recommendations that specify platform and language neutral interfaces in IDL with bindings to EMAScript and other languages. A DOM document is a hierarchy of DOM Nodes which occur as elements, attributes, strings and other derived types. The DOM Node interface provides the means to traverse the node hierarchy and to mutate it through the addition and removal of nodes. There is also a rich model of events with the means to handle events prior to their delivery to the target node, or afterwards, in a capture/buble model. For more details see: http://www.w3.org/DOM/ DOM Events are formally defined in IDL and should thus be amenable to marshalling as messages in a message exchange protocol. More recently, W3C has been looking at extending the DOM to support interpreted user input expressed in XML in application dependent markup and annotated with annotations for such things as timestamps, confidence scores, input modality, alternative recognition hypotheses and other information of interest, see: http://www.w3.org/TR/emma/ EMMA is expected to progress to Last Call Working Draft status within a few weeks from now, and is intended for a wide variety of uses, e.g. speech recognition, pen gestures, interpreted keystrokes, etc. A protocol to support the distribution of DOM events between synchronized DOM's will need to take the DOM event model into account. This includes such things as how to identify the event target (a node in the node hierarchy), and the means for event listeners to stop propagation in either the capture or bubble phases. This is simple when all of the event listeners are in one device, but when some are on one device and some are on another, things get a little more complicated. For DOM updates, I would like to alert people to the work on "XUpdate" done several years ago. See: http://xmldb-org.sourceforge.net/xupdate/ XUpdate serializes DOM Mutation operations as XML messages, and uses XPath to identify where in the node hierarchy a particular operation should be applied. The use of XML to serialize DOM operations makes for a declarative representation and can be straightforwardly applied to IDL datatypes. The semantics are well defined compared with shipping program fragments and this should also simplify security considerations. In applications involving multiple devices, or multiple modality components, such as proposed in the W3C Multimodal Interaction Architecture, there may be more than two instances of the DOM requiring synchronization. Different parts of the DOM tree may be "owned" by different devices. It make sense to consider what kind of access rights model is needed. One possibility is for annotating nodes as being unmutable, or mutable only by the owner, or mutable by all participants. A more complicated approach would be to implement some kind of transactional model with commits and roll-backs. This is probably=20 overkill for the intended purpose of supporting remote user=20 interfaces, but it may be possible for the application to support=20 something like this at a higher level without burdening the DOM=20 synchronization protocol itself. In addition to incremental changes, it will also be necessary to enable to replacement of an entire DOM tree or subtree by another. This is clearly important when starting up. Although session initiation is out of scope for the synchronisation primitives, it is worth working through a simple scenario to provide a fuller context. One possibility is for a client device to use SIP to establish an application session. Once a control path has been established to a server, the server can then send control messages to the client to load the user interface and shared data model. synchronization messages can then be exchanged as the user interacts with the remote application. Finally control messages outside of the scope of the synchronization protocol can be used to terminate the application and release resources. Some assumptions include: 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 - --=20 Dave Raggett W3C lead for multimodal interaction http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC8lcxb3AdEmxAsUsRArmwAKDMow2EwUgKitJuIk5i0TaOevUT6wCgqmK9 mQF+t4jhwA2xQAbfplxw8e4=3D =3Dr8yo -----END PGP SIGNATURE----- _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Mon Aug 08 10:18:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28S9-00011i-6C; Mon, 08 Aug 2005 10:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28S7-00011d-Ln for remoteui@megatron.ietf.org; Mon, 08 Aug 2005 10:18:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23804 for ; Mon, 8 Aug 2005 10:18:05 -0400 (EDT) From: Vlad.Stirbu@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E28zo-0000uW-Hm for remoteui@ietf.org; Mon, 08 Aug 2005 10:52:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j78EBZLL000646; Mon, 8 Aug 2005 17:11:39 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Aug 2005 17:18:02 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Aug 2005 17:18:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's Date: Mon, 8 Aug 2005 17:18:01 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268BA0E755@trebe101.NOE.Nokia.com> Thread-Topic: [REMOTEUI] scoping to synchronizing distributed XML DOM's Thread-Index: AcWZHp/BS6u4UsjQRACM1U+xT6fhegC9wC9Q To: , X-OriginalArrivalTime: 08 Aug 2005 14:18:02.0586 (UTC) FILETIME=[FC9CF3A0:01C59C23] X-Spam-Score: 0.3 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi, On going into solving the generic synchronisation of distributed XML DOM = objects I tend to be a little bit cautious.=20 First of all this group was formed with the purpose of specifying an = open, platform-independent method, the Widget Description Exchange Service, or WiDeX for use in an IP-based = network to convey initialisation, update and eventing information about = user-visible objects, i.e. widgets. We agreed that we don't have to know = the exact nature of these "user-visible" objects and in this regard we = can also say that one way to achieve this is to have the presentation = (expressed as XML DOM objects) synchronised between the UI server and = the UI client. In this context we can clearly say that the network = protocol is stateless; the XML DOM object is "owned" by the server and = whenever network problems are causing synchronisation problems the = client will have to reconnect and re-initialise the presentation state. This is quite different comparing to the situation when we want to keep = also XML DOM objects expressing data synchronised. Who "owns" the XML = DOM or parts of it? What is the access rights model? Dave already = provided some answers and personally I don't think that this working = group is right one to work on these items. I think that the best way to go forward is to focus this work on = defining a stateless message exchange protocol. This way we can keep the = protocol simple for cases like WiDeX, which is DOM stateless on the = client side, and at the same time we can use it in future cases that = will require to manage DOM state on the client side, but in those cases = the access rights model needs to be defined at application(/DOM) layer. Regards, Vlad > -----Original Message----- > From: remoteui-bounces@lists.ietf.org > [mailto:remoteui-bounces@lists.ietf.org]On Behalf Of ext Dave Raggett > Sent: 04 August, 2005 20:58 > To: remoteui@ietf.org > Subject: [REMOTEUI] scoping to synchronizing distributed XML DOM's >=20 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > This is a follow up to the talk I presented at the Remote UI BoF > on 2nd August, see: >=20 > http://www.w3.org/2005/Talks/0802-dsr-ui/ >=20 > I am assuming that everyone on this list is familiar with the > benefits of using markup for representing user interfaces and > the importance of a clean separation between presentation, data > and control for developing applications. XML has been applied to > both the user interface and to the data. and as such it makes > sense to generalize the synchronization mechanism proposed in the > BoF to cover both cases. >=20 > In short, I believe that it would be valuable to develop protocol > support for synchronising distributed XML DOM's. This would > complement existing W3C work on multimodal interaction and device=20 > independence. For MMI, it would support the synchronization of=20 > shared data models as well as distributed multimodal user=20 > interfaces. For DI, it would support the representation of device=20 > capabilities and configuration as DOM nodes when these nodes reflect=20 > properties of remote devices, e.g. remaining paper supplies in a=20 > printer, and also enable thin clients to take part in complex web=20 > applications through a re-factoring of the markup between devices=20 > and servers. >=20 > As was discussed in the BoF, it makes sense to factor out work > on establishing the session context and other aspects related to > device coordination, and to instead focus on just what is needed to > synchronize distributed XML DOM's. The basic scenario is where two > devices hold copies of the same XML document, which could represent > the user interface or a shared data model. DOM events can be raised > in either device and need to be propagated to the other device. > Similarly changes to the XML in one device needs to be propagated > to the other device. The fact that the DOM is distributed is > hidden from the code that is manipulating the DOM. This code could > be a markup language interpreter or scripting engine. >=20 > This is summarised in slide form at: >=20 > http://www.w3.org/2005/Talks/0802-dsr-ui/#[12] >=20 > The DOM is defined by a suite of W3C Recommendations that specify > platform and language neutral interfaces in IDL with bindings to > EMAScript and other languages. A DOM document is a hierarchy of > DOM Nodes which occur as elements, attributes, strings and other > derived types. The DOM Node interface provides the means to traverse > the node hierarchy and to mutate it through the addition and removal > of nodes. There is also a rich model of events with the means to > handle events prior to their delivery to the target node, or > afterwards, in a capture/buble model. For more details see: >=20 > http://www.w3.org/DOM/ >=20 > DOM Events are formally defined in IDL and should thus be amenable > to marshalling as messages in a message exchange protocol. More > recently, W3C has been looking at extending the DOM to support > interpreted user input expressed in XML in application dependent > markup and annotated with annotations for such things as timestamps, > confidence scores, input modality, alternative recognition hypotheses > and other information of interest, see: >=20 > http://www.w3.org/TR/emma/ >=20 > EMMA is expected to progress to Last Call Working Draft status > within a few weeks from now, and is intended for a wide variety > of uses, e.g. speech recognition, pen gestures, interpreted > keystrokes, etc. >=20 > A protocol to support the distribution of DOM events between > synchronized DOM's will need to take the DOM event model into > account. This includes such things as how to identify the event > target (a node in the node hierarchy), and the means for event > listeners to stop propagation in either the capture or bubble > phases. This is simple when all of the event listeners are in > one device, but when some are on one device and some are on > another, things get a little more complicated. >=20 > For DOM updates, I would like to alert people to the work on > "XUpdate" done several years ago. See: >=20 > http://xmldb-org.sourceforge.net/xupdate/ >=20 > XUpdate serializes DOM Mutation operations as XML messages, and > uses XPath to identify where in the node hierarchy a particular > operation should be applied. The use of XML to serialize DOM > operations makes for a declarative representation and can be > straightforwardly applied to IDL datatypes. The semantics are > well defined compared with shipping program fragments and this > should also simplify security considerations. >=20 > In applications involving multiple devices, or multiple modality > components, such as proposed in the W3C Multimodal Interaction > Architecture, there may be more than two instances of the DOM > requiring synchronization. Different parts of the DOM tree may > be "owned" by different devices. It make sense to consider what > kind of access rights model is needed. One possibility is for > annotating nodes as being unmutable, or mutable only by the owner, > or mutable by all participants. >=20 > A more complicated approach would be to implement some kind of > transactional model with commits and roll-backs. This is probably=20 > overkill for the intended purpose of supporting remote user=20 > interfaces, but it may be possible for the application to support=20 > something like this at a higher level without burdening the DOM=20 > synchronization protocol itself. >=20 > In addition to incremental changes, it will also be necessary to > enable to replacement of an entire DOM tree or subtree by another. > This is clearly important when starting up. Although session > initiation is out of scope for the synchronisation primitives, > it is worth working through a simple scenario to provide a fuller > context. One possibility is for a client device to use SIP to > establish an application session. Once a control path has been > established to a server, the server can then send control messages > to the client to load the user interface and shared data model. > synchronization messages can then be exchanged as the user > interacts with the remote application. Finally control messages > outside of the scope of the synchronization protocol can be used > to terminate the application and release resources. >=20 > Some assumptions include: >=20 > a) the fact that the DOM is distributed can be hidden from > the code (markup interpreter or script) operating on the DOM >=20 > b) the synchronization protocol doesn't need to be aware of > the semantics of the markup that is being synchronized. >=20 > c) the synchronization occurs at a fairly loose level that > allows for a simple approach to propagating changes. >=20 > d) latency considerations are important and the user interface > should not block on waiting for replies from other devices >=20 > - --=20 > Dave Raggett W3C lead for multimodal interaction > http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) >=20 > iD8DBQFC8lcxb3AdEmxAsUsRArmwAKDMow2EwUgKitJuIk5i0TaOevUT6wCgqmK9 > mQF+t4jhwA2xQAbfplxw8e4=3D > =3Dr8yo > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > REMOTEUI mailing list > REMOTEUI@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/remoteui >=20 _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Mon Aug 08 11:07:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29Dy-0007je-K1; Mon, 08 Aug 2005 11:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29Dx-0007jZ-7A for remoteui@megatron.ietf.org; Mon, 08 Aug 2005 11:07:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27222 for ; Mon, 8 Aug 2005 11:07:30 -0400 (EDT) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29lf-0002Px-9r for remoteui@ietf.org; Mon, 08 Aug 2005 11:42:24 -0400 Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 1186D4F061; Mon, 8 Aug 2005 11:07:26 -0400 (EDT) Date: Mon, 8 Aug 2005 16:07:32 +0100 (BST) From: Dave Raggett X-X-Sender: dsr@holly To: Vlad.Stirbu@nokia.com Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268BA0E755@trebe101.NOE.Nokia.com> Message-ID: References: <1C1F3D15859526459B4DD0A7A9B2268BA0E755@trebe101.NOE.Nokia.com> X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: remoteui@ietf.org X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 W3C lead for multimodal interaction http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC93U5b3AdEmxAsUsRAoymAKCL5JSCcPCQ9y96jfgYWg6tWY5bBgCfXz97 p5KghIRUbhRpuIOVtL9Do6E= =S7zW -----END PGP SIGNATURE----- _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Tue Aug 09 07:16:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2S62-0004bD-Qc; Tue, 09 Aug 2005 07:16:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2S60-0004b8-Oj for remoteui@megatron.ietf.org; Tue, 09 Aug 2005 07:16:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28902 for ; Tue, 9 Aug 2005 07:16:33 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Sdq-0003gV-Rd for remoteui@ietf.org; Tue, 09 Aug 2005 07:51:35 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j79BBDQE013560; Tue, 9 Aug 2005 07:11:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's Date: Tue, 9 Aug 2005 07:11:09 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647A06B08@ATLANTIS.Brooktrout.com> Thread-Topic: [REMOTEUI] scoping to synchronizing distributed XML DOM's Thread-Index: AcWcKwLh3v6+w5VPRbGWyi/G3MnjjgApzFAw From: "Eric Burger" To: "Dave Raggett" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: remoteui@ietf.org X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org 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: remoteui-bounces@lists.ietf.org [mailto:remoteui-bounces@lists.ietf.org] On Behalf Of Dave Raggett Sent: Monday, August 08, 2005 11:08 AM To: Vlad.Stirbu@nokia.com Cc: remoteui@ietf.org Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Like Eric, I believe that scoping a protocol to a well characterised=20 problem with broad appeal is important to achieving a successful=20 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=20 models. XHTML, SVG, SMIL, XForms, XAML, and XUL are examples of this trend. The combination of XML and scripting is also very popular,=20 whether on cell phones, desktops or on servers. A protocol for=20 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 - --=20 Dave Raggett W3C lead for multimodal interaction http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC93U5b3AdEmxAsUsRAoymAKCL5JSCcPCQ9y96jfgYWg6tWY5bBgCfXz97 p5KghIRUbhRpuIOVtL9Do6E=3D =3DS7zW -----END PGP SIGNATURE----- _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Tue Aug 09 09:16:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Txs-000100-28; Tue, 09 Aug 2005 09:16:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Txq-0000zM-Iz for remoteui@megatron.ietf.org; Tue, 09 Aug 2005 09:16:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05240 for ; Tue, 9 Aug 2005 09:16:16 -0400 (EDT) From: Vlad.Stirbu@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2UVk-0007Aw-RB for remoteui@ietf.org; Tue, 09 Aug 2005 09:51:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j79DBYKE001357; Tue, 9 Aug 2005 16:14:36 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 16:12:19 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 16:12:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's Date: Tue, 9 Aug 2005 16:12:16 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268BA0E766@trebe101.NOE.Nokia.com> Thread-Topic: [REMOTEUI] scoping to synchronizing distributed XML DOM's Thread-Index: AcWcKwLh3v6+w5VPRbGWyi/G3MnjjgApzFAwAAH6YvA= To: , X-OriginalArrivalTime: 09 Aug 2005 13:12:16.0957 (UTC) FILETIME=[F73F7ED0:01C59CE3] X-Spam-Score: 0.3 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Cc: remoteui@ietf.org X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org It seems to me that looking at marshalling DOM Events and sending them = over the wire is a good start. With this in mind we can create a = protocol that offers the *primitives* that enables XML DOM = synchronisation. The actual synchronisation is a different matter and we = already see several possibilities for doing so, some of them extremely = simple and some more complicated depending on the environment that is = targeted. In RUI/WiDeX context things are easy: the UI server "owns" the DOM = object, UI client is stateless, the nature of the updates is different = on UI server and UI client, update collisions are unlikely (for a well = behaving application). Looking at what kind of deliverables this group can produce, I see the = following: 1. Requirements document 2. Protocol providing the synchronisation primitives 3. UI remoting framework describing how to use the protocol in this = context and how to interact with other sub-systems (i.e. service = discovery). Splitting the work in this way we solve the UI remoting problem in a = generic way by enabling the possibility to reuse the protocol for other = environments. Additionally, we will be able to deliver something in a = fairly short time with low complexity and also build a solid basis for = further development. I also feel that we need to provide the right tool for a particular = environment and in this case by having a one-size-fits-all "generic" = synchronisation protocol will add unnecessary burden on some simple = devices. Cheers, Vlad > -----Original Message----- > From: remoteui-bounces@lists.ietf.org > [mailto:remoteui-bounces@lists.ietf.org]On Behalf Of ext Eric Burger > Sent: 09 August, 2005 14:11 > To: Dave Raggett > Cc: remoteui@ietf.org > Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's >=20 >=20 > Sounds good. However, I guess I get to play on both sides of this > fence. >=20 > 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. >=20 > The one that immediately comes to mind as not being (cleanly)=20 > 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=20 > restored, > how does one reconcile conflicting updates? It is easy if=20 > the "server" > (in Vlad's terminology) owns the tree. Updates only ever get sent out > to the "client". >=20 > Given the user interface in the rmt model simply manipulates=20 > 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. >=20 > Looking at the word choice above, one could make things=20 > "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. >=20 > -----Original Message----- > From: remoteui-bounces@lists.ietf.org > [mailto:remoteui-bounces@lists.ietf.org] On Behalf Of Dave Raggett > Sent: Monday, August 08, 2005 11:08 AM > To: Vlad.Stirbu@nokia.com > Cc: remoteui@ietf.org > Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Like Eric, I believe that scoping a protocol to a well characterised=20 > problem with broad appeal is important to achieving a successful=20 > 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=20 > models. XHTML, SVG, SMIL, XForms, XAML, and XUL are examples of this > trend. The combination of XML and scripting is also very popular,=20 > whether on cell phones, desktops or on servers. A protocol for=20 > synchronizing XML DOM's has the potential to widely useful. >=20 > With regards to your specific points: >=20 > 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. >=20 > 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. >=20 > What about the assumptions I proposed? >=20 > a) the fact that the DOM is distributed can be hidden from > the code (markup interpreter or script) operating on the DOM >=20 > b) the synchronization protocol doesn't need to be aware of > the semantics of the markup that is being synchronized. >=20 > c) the synchronization occurs at a fairly loose level that > allows for a simple approach to propagating changes. >=20 > d) latency considerations are important and the user interface > should not block on waiting for replies from other devices >=20 > To which I would add: >=20 > e) the state is held in the DOM allowing the synchronization > protocol itself to be stateless >=20 > - --=20 > Dave Raggett W3C lead for multimodal interaction > http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) >=20 > iD8DBQFC93U5b3AdEmxAsUsRAoymAKCL5JSCcPCQ9y96jfgYWg6tWY5bBgCfXz97 > p5KghIRUbhRpuIOVtL9Do6E=3D > =3DS7zW > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > REMOTEUI mailing list > REMOTEUI@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/remoteui >=20 > _______________________________________________ > REMOTEUI mailing list > REMOTEUI@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/remoteui >=20 _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Tue Aug 09 10:54:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VUh-00019a-FZ; Tue, 09 Aug 2005 10:54:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VUf-00019P-HM for remoteui@megatron.ietf.org; Tue, 09 Aug 2005 10:54:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13163 for ; Tue, 9 Aug 2005 10:54:15 -0400 (EDT) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2W2b-00023M-1G for remoteui@ietf.org; Tue, 09 Aug 2005 11:29:21 -0400 Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id CD94E4F08F; Tue, 9 Aug 2005 10:54:13 -0400 (EDT) Date: Tue, 9 Aug 2005 15:54:21 +0100 (BST) From: Dave Raggett X-X-Sender: dsr@holly To: Eric Burger Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's In-Reply-To: <330A23D8336C0346B5C1A5BB19666647A06B08@ATLANTIS.Brooktrout.com> Message-ID: References: <330A23D8336C0346B5C1A5BB19666647A06B08@ATLANTIS.Brooktrout.com> X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: remoteui@ietf.org X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Dave Raggett W3C lead for multimodal interaction http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC+MOhb3AdEmxAsUsRAqlBAJ9UkbHE3c4qHarDVmN/Nmoj0jAYGwCeKJ26 tVNADHhMJSXK1NALDNmnsBc= =Alq6 -----END PGP SIGNATURE----- _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Wed Aug 10 08:09:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pP4-0001zy-Bk; Wed, 10 Aug 2005 08:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pP2-0001zt-QZ for remoteui@megatron.ietf.org; Wed, 10 Aug 2005 08:09:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23007 for ; Wed, 10 Aug 2005 08:09:47 -0400 (EDT) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2px8-00049d-Hc for remoteui@ietf.org; Wed, 10 Aug 2005 08:45:03 -0400 Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 342484F14F; Wed, 10 Aug 2005 08:09:46 -0400 (EDT) Date: Wed, 10 Aug 2005 13:09:54 +0100 (BST) From: Dave Raggett X-X-Sender: dsr@holly To: Vlad.Stirbu@nokia.com Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268BA0E766@trebe101.NOE.Nokia.com> Message-ID: References: <1C1F3D15859526459B4DD0A7A9B2268BA0E766@trebe101.NOE.Nokia.com> X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: remoteui@ietf.org X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think we have a rough agreement on the idea of marshalling DOM events as XML messages, and on representing DOM updates in XML with XPath as a means to identify where the updates apply. I perceive open issues such as support for the capture/bubble model of DOM events, and whether only the server can do DOM updates, or whether this can be generalised in a lightweight way. These merit further study on the pros and cons. I think we are also in agreement that the means to establish sessions and support for device coordination should be factored out and not addressed by the remote UI protocol. When it comes to motivation, I believe that we are in agreement on enabling remote user interfaces on a range of devices from simple to complex. However, that is a little too abstract on its own, and I recommend that we ground the charter in the context of working going on elsewhere, including that at W3C. An XML-based protocol to convey DOM events and DOM updates looks likely to be of high value to implementing the W3C Multimodal Interaction architecture[1], to enabling dynamic adaptation to the delivery context[2], and more generally as a means to enable the refactoring of device independent markup[3] between the client and server for thin clients, where a web page "runs" on the server with small pieces dispatched to the thin client and kept in sync with the server via the remote UI protocol. I would be happy to collaborate on drafting a proposed charter that covers requirements and an associated protocol for DOM events and updates. The charter should mention open issues and ground the work in terms of uses cases and the relation to other work, including that at W3C. We should also explain why session establishment is out of scope and how existing approaches can be used to address it. For some context on that, see my W3C presentation on the Ubiquitous Web[4]. [1] http://www.w3.org/TR/mmi-arch/ [2] http://www.w3.org/TR/DPF/ [3] http://www.w3.org/2001/di/ [4] ttp://www.w3.org/2005/Talks/0621-dsr-ubiweb/ Is this adequate as a basis for moving forward? - -- Dave Raggett W3C lead for multimodal interaction http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC+e6Xb3AdEmxAsUsRAnHPAJ0WjMHFleKBbjNHI7nDxKOhAwywawCdFLqr 8izEvCpwGrmXER6W9TZzUaI= =7iNl -----END PGP SIGNATURE----- _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Tue Aug 23 20:36:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7jFY-0007sz-AX; Tue, 23 Aug 2005 20:36:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7jFW-0007sp-LF for remoteui@megatron.ietf.org; Tue, 23 Aug 2005 20:36:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22205 for ; Tue, 23 Aug 2005 20:36:13 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7jFi-0003MW-Vf for remoteui@ietf.org; Tue, 23 Aug 2005 20:36:28 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j7O0UC93011115; Tue, 23 Aug 2005 20:30:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Aug 2005 20:30:08 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647E06579@ATLANTIS.Brooktrout.com> Thread-Topic: Continued interest Thread-Index: AcWdpGgvAdza6lk2RF+TufRmg0r9XAKnmCAA From: "Eric Burger" To: "Dave Raggett" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: remoteui@ietf.org Subject: [REMOTEUI] Continued interest X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org On the one hand, I would say, "go ahead, propose a charter." On the other hand, it looks like you, me, and Vlad are the only ones who care. Does anyone else care? -----Original Message----- From: Dave Raggett [mailto:dsr@w3.org]=20 Sent: Wednesday, August 10, 2005 8:10 AM To: Vlad.Stirbu@nokia.com Cc: Eric Burger; remoteui@ietf.org Subject: RE: [REMOTEUI] scoping to synchronizing distributed XML DOM's -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think we have a rough agreement on the idea of marshalling DOM=20 events as XML messages, and on representing DOM updates in XML with=20 XPath as a means to identify where the updates apply. I perceive=20 open issues such as support for the capture/bubble model of DOM=20 events, and whether only the server can do DOM updates, or whether=20 this can be generalised in a lightweight way. These merit further study on the pros and cons. I think we are also in agreement that the means to establish sessions and support for device coordination should be factored out and not addressed by the remote UI protocol. When it comes to motivation, I believe that we are in agreement on=20 enabling remote user interfaces on a range of devices from simple to=20 complex. However, that is a little too abstract on its own, and I recommend that we ground the charter in the context of working going on elsewhere, including that at W3C. An XML-based protocol to convey DOM events and DOM updates looks=20 likely to be of high value to implementing the W3C Multimodal=20 Interaction architecture[1], to enabling dynamic adaptation to the=20 delivery context[2], and more generally as a means to enable the=20 refactoring of device independent markup[3] between the client and=20 server for thin clients, where a web page "runs" on the server with=20 small pieces dispatched to the thin client and kept in sync with the=20 server via the remote UI protocol. I would be happy to collaborate on drafting a proposed charter that=20 covers requirements and an associated protocol for DOM events and=20 updates. The charter should mention open issues and ground the work=20 in terms of uses cases and the relation to other work, including=20 that at W3C. We should also explain why session establishment is out=20 of scope and how existing approaches can be used to address it. For=20 some context on that, see my W3C presentation on the Ubiquitous=20 Web[4]. [1] http://www.w3.org/TR/mmi-arch/ [2] http://www.w3.org/TR/DPF/ [3] http://www.w3.org/2001/di/ [4] ttp://www.w3.org/2005/Talks/0621-dsr-ubiweb/ Is this adequate as a basis for moving forward? - --=20 Dave Raggett W3C lead for multimodal interaction http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC+e6Xb3AdEmxAsUsRAnHPAJ0WjMHFleKBbjNHI7nDxKOhAwywawCdFLqr 8izEvCpwGrmXER6W9TZzUaI=3D =3D7iNl -----END PGP SIGNATURE----- _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Thu Aug 25 08:58:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HJE-0007r0-PB; Thu, 25 Aug 2005 08:58:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HJ8-0007pA-Jc for remoteui@megatron.ietf.org; Thu, 25 Aug 2005 08:58:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16145 for ; Thu, 25 Aug 2005 08:58:12 -0400 (EDT) From: Vlad.Stirbu@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8HJc-0002Iy-Ou for remoteui@ietf.org; Thu, 25 Aug 2005 08:58:47 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7PCw7x4015177 for ; Thu, 25 Aug 2005 15:58:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Aug 2005 15:58:09 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Aug 2005 15:58:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Aug 2005 15:58:09 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268BA0E7BF@trebe101.NOE.Nokia.com> Thread-Topic: Widex charter proposal draft Thread-Index: AcWpdKUU3+FIH985RLWK/1wkCzNMWw== To: X-OriginalArrivalTime: 25 Aug 2005 12:58:09.0572 (UTC) FILETIME=[A4C6CE40:01C5A974] X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: Subject: [REMOTEUI] Widex charter proposal draft X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi, Please find below the charter proposal for the WiDeX WG. Regards, Vlad -------------------------------------------------------------------------= ----------------- Description of Working Group UI remoting is a technique whereby a user interface is rendered on other = devices than those that run the application logic.=20 A widget is an element of a user interface (UI) that displays = information or provides a specific way for a user to interact with the = operating system and application. Widgets may for instance include = icons, pull-down menus, buttons, selection boxes, progress indicators, = on-off checkmarks, scroll bars, windows, window edges (that let you = resize the window), toggle buttons, forms, and many other devices for = displaying information and for inviting, accepting, and responding to = user actions. Widget-level UI remoting provides a mechanism that enables a client = device to process widget descriptions received from a server device, = keeping the client UI synchronized with the application logic. The WiDeX (Widget Description Exchange Service) WG will define a = standard mechanism that can be used in an IP-based network for conveing = initialization, update and eventing information about user visible = objects, i.e. widgets. The WG will strive to preserve an extensible architecture so that the = work possibly be useful in the future with other types of descriptive = user interfaces beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - XML representation of user interface objects. - Means to establish sessions and support for device coordination. The WiDeX service definition will define: - A mechanism for synchronizing distributed XML DOM objects by = propagating DOM mutations/updates and DOM events. - A set of parameters that need to be negotiated by a service discovery = and session setup mechanism in order to start the UI remoting session. - A framework that enables a widget-level UI remoting mechanism using = distributed XML DOM synchronization and a service discovery and session = setup mechanism as building blocks. Deliverables: - Requirements document. - Document specifying the stateless protocol for synchronizing XML DOM = objects. - Document specifying the framework for widget-level UI remoting. It is possible that work undertaken in other working groups and even = other standards bodies (i.e. W3C) will be referenced by this working = group. It is even possible that entire deliverables could be satisfied = by the work of other working groups (i.e. discovery protocols). This = working group will seek to maximize the use of existing specifications = where applicable. Goals and Milestones: TBD. Internet-Drafts: LRDP: The Lightweight Remote Display Protocol, = http://www.ietf.org/internet-drafts/draft-stirbu-lrdp-00.txt _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Fri Aug 26 16:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8l9l-0006Of-Kk; Fri, 26 Aug 2005 16:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8l9e-0006Mz-Uc for remoteui@megatron.ietf.org; Fri, 26 Aug 2005 16:50:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21935 for ; Fri, 26 Aug 2005 16:50:24 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8lAS-000715-5X for remoteui@ietf.org; Fri, 26 Aug 2005 16:51:16 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j7QKix0o024220; Fri, 26 Aug 2005 16:44:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [REMOTEUI] Widex charter proposal draft Date: Fri, 26 Aug 2005 16:44:56 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647E6490C@ATLANTIS.Brooktrout.com> Thread-Topic: [REMOTEUI] Widex charter proposal draft Thread-Index: AcWpdKUU3+FIH985RLWK/1wkCzNMWwBCOjNw From: "Eric Burger" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: remoteui@ietf.org X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Looks good. The only comment I would offer is that while the first focus of the protocol is for the support of updating DOM's that represent user interfaces, such a protocol should be generally useful for updating DOM's. Said differently, the first three paragraphs, or about 60%, of the proposed charter talk about user interface widgets (menus, drop boxes, text, etc.). However, the protocol has NOTHING to do with widgets. To my mind, the protocol is about partial synchronization of DOM's. It just happens that *your* application for such a synchronization is for updating remote user interfaces. *My* application may be for something entirely different, like pushing state in CCXML. The beauty of the DOM is the protocol should not (can not?) care about what the semantics of the DOM updates are. If it does, we are doomed. All we would be doing is creating a fixed protocol to transfer a fixed semantic DOM. That isn't interesting and I would offer would be obsolete by the time we're done. I would honor the widget exchange use case by using it as an *example* of what the protocol is going to be used for. Since it is cool, one might even keep the Widex name. Moreover, the charter might say that the work group will err on the side of supporting the user interface use case for DOM synchronization. However, unless I am mistaken, I do not see any difference between a "DOM synchronization protocol" and a "User Interface Widget DOM synchronization protocol." -----Original Message----- From: remoteui-bounces@lists.ietf.org [mailto:remoteui-bounces@lists.ietf.org] On Behalf Of Vlad.Stirbu@nokia.com Sent: Thursday, August 25, 2005 8:58 AM To: remoteui@ietf.org Subject: [REMOTEUI] Widex charter proposal draft Hi, Please find below the charter proposal for the WiDeX WG. Regards, Vlad ------------------------------------------------------------------------ ------------------ Description of Working Group UI remoting is a technique whereby a user interface is rendered on other devices than those that run the application logic.=20 A widget is an element of a user interface (UI) that displays information or provides a specific way for a user to interact with the operating system and application. Widgets may for instance include icons, pull-down menus, buttons, selection boxes, progress indicators, on-off checkmarks, scroll bars, windows, window edges (that let you resize the window), toggle buttons, forms, and many other devices for displaying information and for inviting, accepting, and responding to user actions. Widget-level UI remoting provides a mechanism that enables a client device to process widget descriptions received from a server device, keeping the client UI synchronized with the application logic. The WiDeX (Widget Description Exchange Service) WG will define a standard mechanism that can be used in an IP-based network for conveing initialization, update and eventing information about user visible objects, i.e. widgets. The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future with other types of descriptive user interfaces beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - XML representation of user interface objects. - Means to establish sessions and support for device coordination. The WiDeX service definition will define: - A mechanism for synchronizing distributed XML DOM objects by propagating DOM mutations/updates and DOM events. - A set of parameters that need to be negotiated by a service discovery and session setup mechanism in order to start the UI remoting session. - A framework that enables a widget-level UI remoting mechanism using distributed XML DOM synchronization and a service discovery and session setup mechanism as building blocks. Deliverables: - Requirements document. - Document specifying the stateless protocol for synchronizing XML DOM objects. - Document specifying the framework for widget-level UI remoting. It is possible that work undertaken in other working groups and even other standards bodies (i.e. W3C) will be referenced by this working group. It is even possible that entire deliverables could be satisfied by the work of other working groups (i.e. discovery protocols). This working group will seek to maximize the use of existing specifications where applicable. Goals and Milestones: TBD. Internet-Drafts: LRDP: The Lightweight Remote Display Protocol, http://www.ietf.org/internet-drafts/draft-stirbu-lrdp-00.txt _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Wed Aug 31 22:22:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAeiI-0002dB-VE; Wed, 31 Aug 2005 22:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAeiH-0002cu-Cq for remoteui@megatron.ietf.org; Wed, 31 Aug 2005 22:22:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02993 for ; Wed, 31 Aug 2005 22:21:58 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAek8-0003B9-LE for remoteui@ietf.org; Wed, 31 Aug 2005 22:23:57 -0400 Received: from [192.168.2.102] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j812QHsm028679 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 31 Aug 2005 21:26:17 -0500 In-Reply-To: <330A23D8336C0346B5C1A5BB19666647E06579@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB19666647E06579@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v622) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <09af4f815f37328c2f7cf69db7a5d3ab@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 31 Aug 2005 21:21:54 -0500 To: remoteui@ietf.org X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Content-Transfer-Encoding: 7bit Cc: Vlad.Stirbu@nokia.com Subject: [REMOTEUI] Minutes from Remote UI BOF at IETF 63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org The draft minutes from our recent BoF are posted at: http://www.softarmor.com/rui/meets/ietf63/notes/minutes-rui-ietf63.html Text follows. Please review for accuracy and report any comments to me before mid-day Friday Sep. 2, US CST. --------------- Draft Minutes, Remote UI at IETF 63 Edited by Dean Willis from notes by Randall Gellens Chair called to order with IPR notice and reminder to use new draft boilerplate and idnits tool. Agenda reviewed and approved as posted. Topic: Possible scope and deliverables, discussion led by chairs. Slides presented Question: : does "proposed deliverables" slide suggest we've already decided what to do? Dean: no, it suggests what we might do if we decide to do something. Vlad: "remote user interface" may no longer we appropriate name; we have narrowed our scope. Topic: W3C work on related topics, led by Dave Raggett Slides presented. web limitations (visual, mouse, limited devices, etc.) - overview of web (resources, languages/formats, protocols, etc.) - separation of presentation from views, data model from ???, etc. - the DOM: platform and language neutral APIs for manipulating XML documents with a rich model of events - DOM enhancements (user prefs, device capabilities, configuration, environmental conditions, access to remote services) - layering APIs on protocols (DOM property w/ GET/SET methods) - propagation of local events (e.g., device out of paper) - speech, keypad, or pen for user input (cars) - variety of output options - dialog between user and application (expressed via markup, client/server scripts) - who is in control (user, wizards) - xml data exchange between input processors and interaction mgmt systems - processors annotate application specific data with confidence scores, timestamps, input/output modes, partial results, etc. - no standards-based solutions yet; contributions on SALT and X+V - W3C MMI WG developing architecture - other protocols possible - modality components communicate via asynch msgs (DOM may hide protocol) - distributed DOM events (events signaling changes to user prefs, device config/capabilities, environmental conditions, shared data model) - propagate changes to shared data model - synchronize local copies of remote properties (ink levels in network printer, geo loc of device) Conclusion: W3C should do markup, DOM, IETF do remote protocol Topic: Proposed RemoteUI solution, discussion led by Vlad Stirbu Slides presented Remote UI is intended to be a mechanism to allow user interface to be rendered on separate device from application logic. - compare to alternatives (framebuffer [VNC, RDP, Hot Desk], graphics-level [x-windows]) - problem with these: UI is slave to logic; can't adapt to device or user or environment - widely diverse device characteristics UI descriptions (W3C markup languages; discovery session setup [mmusic]) - WiDeX Goal & Scope (specify an open platform-independent method for use in an IP network for user-visible objects) - WiDeX requirements and assumptions Question: what does "discovery and session setup independent" mean? - Vlad: need to be able to use multiple mechanisms, e.g., SDP, zero-conf - Dean: KPML uses SIP-session setup for discovery, then SIP to carry events, but Remote UI may want to use other protocols and it might be desirable to use SIP for everything. (Ed. note: see draft-stirbu-ordp-00) MVC* Architecture overview - MVC elements (model, view, controller) - Remoting UI Concept - MVC Architecture Over the Network - WiDeX Framework Overview Question: this looks like specifying ui behavior, not over-the-wire protocol - Vlad: no, scope is limited to protocol; UI elements and behavior out of scope - Comment: this gives context to protocol since IETF normally doesn't do UI - Dean: need UI that can be described semantically; need to be able to split into model/view/controller; need to be able to synchronize events Comment: document looks like it focuses on UI; should rename document "how to keep DOMs synchronized" Comment: use of "client" and "server" is confusing, doesn't look like x-windows terms - Dean: no, this is web-server terms Comment: saying session setup is out of scope is not right - Vlad: maybe so Comment : scope is keeping state synchronized, after session has been setup - Vlad: you are doing synchronization, but you don't care how UI is represented Comment: "keeping ui in sync" keeps being said; better to focus on keeping DOM in sync Chair: We seem to have a scoping proposal to focus on keeping DOMs in sync. Comment: session setup happens before synchronization, may need separate protocol; my web page says 'here is URL for my pvi; you can click but you don't know what widgets will be sent - protocol may not care what widgets are sent Comment: W3C will provide framework for (Ed: missed here, but presumably "widget definition") Comment: Vlad was talking about need for protocol that can be used for several things; W3C folks want to aim for DOM; to do something general purpose you need at least one specific thing it is good for, otherwise it is likely good for nothing; WG should have specific goal to make DOM object synchronization work, but it should not make a protocol that is limited to this. Comment: negotiation-then-transport is like RTP (SDP then payload formats); important that this be specified someplace Comment: session startup discussion is confusing; best guess is that session initiation is a sequence that eventually sends payload; URI reference is a way to start; at some point thing doing exchange and update has to start by negotiating; that phase has to take place as part of this protocol. Comment: device characteristics versus large database are PFM as far as this group is concerned; can think of at least 5 mechanisms (SDP, RTSP, etc.); we don't need yet another one Dean: how does synchronizing two XML documents differ from SIMPLE presence distribution? Question: unclear on intent - Vlad: you are synchronizing two DOM objects; don't need to have stateful devices or applications; only application logic is maintaining state of system; everything is related to application logic; UI is representation of that Comment (Crocker): I'm jet lagged; please raise hand if you believe you understand scope of work - a number of people raised hands, perhaps 20% of room, questioner seems impressed. Comment: I'm finishing my PhD in pretty much this, so yes; I'd suggest that a document that described how to use this with mobile phones with SIP would be needed; this does need to be used for something; this group needs to explain how it works - Vlad: SIP in Minneapolis concluded that SIP/SDP needs protocol to show what needs to be synchronized Comment: I think I understand chewy center of scope; unclear where hard candy boundary is (limits of scope, only core of scope is clear); which parts of service discovery get included; what are other ends of protocols; the more general this gets the harder it is to understand; pick something specific (e.g., XML documents) and keep that in focus; otherwise scope gets out of hand Comment: client need not be stateful -- if true, example is video; don't need to sync back to server that you rec'd video; may have to sync when formats change so client and server are on same page; so client needs to be stateful - Dean: video with streams is an important issue; because we are using UI descriptions to instantiate widgets that interact with the application. We could use embedded widgets to play video; send events when video is completed. - Comment: you just described a state machine - Dean: Then I suppose clients may have state. Comment: recommend not doing general solution that has one specific solution; instead do specific solution that can be used for other things (back to slides) Questions - MVC right for WiDeX? - more fine-grained UI exhange msgs? - Beep right protocol?) Dean: this draft is so lightweight there's not really any protocol there. Chris: like SASL Comment: synchronizing client state with server has been done before; IMAP is one; ACAP is another that had a much simpler data model than XML; caution since we've failed before. BEEP sounds like slam dunk since you're using XML and need multiple channels Comment: XMPP may be right; doesn't have multiple channels of BEEP Comment: could use on top of SIP events Comment: what is interoperation point? If it is network for lots of configuration points, there are lots of network elements that talk to each other; that's not what we're doing here; classic way to do this is write application, split into two pieces (client and server); use private protocol between them; why do you need to expose nature of content? - Vlad: you don't expose nature of content Comment: this problem is in application domain; don't need a network protocol - Dean: assumption that client is independent of application; protocol definition between two elements to enable application without having to download software to understand UI elements Dean (as chair) asks how many optimists in room? If there work is here for IETF, please raise hand (a large number do) Dean asks to raise hand if you think this is out of scope of IETF (a few hands go up) Dean asks what we can do to better understand problem so all hands on are same side; need architecture model and maybe requirements document Comment: my hand was half-up; it isn't clear that we have bounds; we need to charter-bash and see if we can get reasonable bounds Scott (AD): mailing list (remoteui@ietf.org) is available; we need to refine scope and work on boundaries; we need to do this on the mailing list; next step is to put together charter to define goals Dean: we'll continue with charter discussion on mailing list Comment: why would I use this instead of, e.g., Sun's JINI? Dean: I had same question; objection description in JINI is a Java program; much worse security implications, larger size, need full JVM, etc. We need a semantic model, no arbitrary execution of code, limited execution, no JVM, etc. Comment: would be helpful to have requirements from W3C; there are a lot of really cool and nifty things we could do that no one would care about; a goals document would help _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui