Subject: RE: [REMOTEUI] Widex charter proposal draft

From: "Eric Burger" <[email-masked]>
Date: Thu, 1 Sep 2005 22:01:58 -0400

I would agree on limiting the protocol to SIP, but we should have a
draft explaining why.  Namely, it is because the updates are
bi-directional.  If they were uni-directional, HTTP would probably do.

I would volunteer, but I have to finish my thesis first, and that
wouldn't make it as a chapter :)

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Raggett
Sent: Thursday, September 01, 2005 10:42 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [REMOTEUI] Widex charter proposal draft

Some further questions.

To make the protocol more concrete we might want to bind it to
SIP and to mention this in the charter.

SIP is an obvious choice because of its use for establishing
sessions and for distributing events (represented in XML),
although the focus has hitherto been on presence information.
SIP is also widely deployed on desktop and mobile devices.
Web Services and the widespread deployment of HTTP make the
latter another candidate worthy of discussion.

We could also use the charter to constrain the work by mentioning
technical assumptions. Here are two that I have thought of:

First, when an event is raised in the user interface, the DOM is 
responsible for passing it to event handlers according to the
DOM event capture/bubble model. If an event is passed to a remote 
handler, the User interface should be able to pass the event to
the next handler without having to worry about whether or not the
remote handler calls the stopPropagation method. A similar concern
relates to the preventDefault method. I therefore suggest that
these two methods have no effect when called by a remote handler
of a DOM event. This ensure that events can be asynchronously
passed off to remote handlers.

Second, if the user interface wants to modify the document, it
is required to pass the request as an event to the document owner
which is then responsible for making the corresponding changes.
Note that the user interface may involve more than one document
and that these may have different owners. Moreover, this only
applies to documents that are under synchronization. Other
documents may be freely updated by default event handlers or
local scripts.

We may also want to constrain what we intend for the framework
for session initiation. For instance, in:

   http://whatwg.org/specs/web-apps/current-work/#server-sent

section 6.1.2 defines an extension to the DOM for a 
RemoteEventTarget interface that should be supported by any
object that implements the DOM EventTarget interface. The idea
is to use URIs to specify the means to subscribe to an event
or list of events and correspondingly to unsubscribe:

    // src is used for a URI in both cases
    interface RemoteEventTarget {
       void addEventSource(in DOMString src);
       void removeEventSource(in DOMString src);
    };

This is fine for sourcing events from a remote device, but 
inadequate for our purposes where the UI device needs to
send selected events to a sink on the application server,
and to receive DOM mutation/update operations from that
server. Is this information expressed in the UI markup and
acted upon by the markup language interpreter, or is it set
up via an out of band mechanism such as the SIP/SDP etc.
where the information is passed separately to the markup.

- -- 
  Dave Raggett <[email-masked]>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

_______________________________________________
REMOTEUI mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/remoteui

_______________________________________________
REMOTEUI mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/remoteui