RE: [Widex] Proposed rewording for Framework draft

"Jin Yu" <jyu@openxup.org> Fri, 16 June 2006 13:47 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEfD-0000jc-SE; Fri, 16 Jun 2006 09:47:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEfD-0000iQ-1u for widex@ietf.org; Fri, 16 Jun 2006 09:47:07 -0400
Received: from smtp103.sbc.mail.mud.yahoo.com ([68.142.198.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrEfB-0006Iz-Dx for widex@ietf.org; Fri, 16 Jun 2006 09:47:07 -0400
Received: (qmail 53439 invoked from network); 16 Jun 2006 13:47:04 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@143.89.91.139 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 16 Jun 2006 13:47:04 -0000
From: Jin Yu <jyu@openxup.org>
To: 'Dave Raggett' <dsr@w3.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Fri, 16 Jun 2006 06:46:46 -0700
Organization: OpenXUP.org
Message-ID: <000f01c6914b$52896ab0$1e02a8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Thread-Index: AcaRITZxWEESd5kPTRKlMn0ygsfPMQAJjqSg
In-Reply-To: <Pine.LNX.4.62.0606160916060.8838@localhost.localdomain>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

> So how about:
> 
>   With the DOM Event model it is possible to attach multiple
>   event listeners for the same event. The DOM event model
>   defines an ordering in which the listeners are invoked, and
>   provides a means to stop further propagation of the event,
>   and to prevent the default event handler from being invoked.
>   In the case of a mix of local and remote event listeners,
>   depending on where they are attached, a local event listener
>   could stop further propagation and thereby prevent the remote
>   event listener from being invoked. The other way around is
>   more complicated. The stub used by the Widex Renderer for
>   remote event listeners could itself stop further propagation,
>   but there would be undue latency incurred if this was to be
>   done by the corresponding event handler in the Widex Server.
> 
> Which leaves open the possibility for WO.Selector messages
> to specify whether or not the event listener stub used in
> the Widex Renderer should call the preventDefault method or
> the stopPropagation method on DOM events.

Sounds good.

> > I think we could just rephrase your paragraph a bit, implying it's
> > a possible implementation approach. Also, I don't quite understand
> > the last sentence - what do you mean by "explicit view"? My
> > understanding is that the server's view is always virtual, whereas
> > the renderer keeps the concrete (or physical) view.
> 
> It is up to the implementation whether or not the Widex Server
> has a virtual or explicit XML DOM for the View. However, that
> has no effect on the Widex Protocol.
> 
> So how about:
> 
>   In an implementation where the Widex Server maintains
>   an explicit XML DOM for the View, changes made by the
>   Widex Server to this View result in DOM events, e.g.
>   DOM Mutation events. The Widex Framework in the server
>   (as shown in Figure 1) can listen for these events to
>   generate the corresponding Widex messages. The Widex
>   Framework in the Renderer interprets these messages to
>   reflect the changes to its copy of the XML DOM for the
>   View. Note that the Widex messages are independent of
>   whether the Widex Server has an explicit or a virtual
>   View.

Sorry but I'm still a bit confused about the meaning of "explicit view", after
your explanation above and Vlad's explanation in the other email:

> The "explicit view" on the Widex Server is when the UI exported through
> Widex is of a desktop application, case in which a physical view is kept
> also on the Widex Server.

What's the difference between desktop app and non-desktop app? If you are
referring to web apps, then I don't see a difference here. In both cases, the
server would keep a virtual DOM / view (e.g. HTML DOM for web app, XUL DOM for
desktop app), and the physical view is kept in the renderer.

Or perhaps when you say desktop app, you are referring to X11-based app. In that
case, the roles are reversed. The server is indeed keeping a physical view,
whereas the client is keeping a virtual view. To me, Widex is the reverse of
X11, so I guess our Widex server shouldn't be keeping physical view.

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


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