Subject: [Widex] Proposed rewording for Framework draft

From: Dave Raggett <[email-masked]>
Date: Wed, 14 Jun 2006 12:40:16 +0100 (BST)

It seems that Jin isn't keen on the use of the term "programming
level" in section 3.1, so how about replacing:

  DOM model describes mainly two ways to associate an event
  listener to a node in the tree:

  1.  at the programming level, using the EventTarget interface as
      specified by DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413]
      or a method specific to the UI markup language.
  2.  at the document level, using XML Events
      [W3C.REC-xml-events-20031014] or an ad-hoc syntax, as the
      ones provided by the UI markup language itself, e.g.  XHTML
      [W3C.REC-xhtml1-20020801] or SVG 1.1 [W3C.REC-SVG11-20030114].

By

  The DOM describes two ways to associate an event
  listener to a node in the tree:

  1.  Using the DOM EventTarget interface as specified by
      DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413] or a
      method specific to the UI markup language.
  2.  Using markup, either with XML Events
      [W3C.REC-xml-events-20031014] or a language specific
      syntax, e.g.  XHTML [W3C.REC-xhtml1-20020801] or SVG 1.1
      [W3C.REC-SVG11-20030114].

And replacing:

  Following the DOM model, associating event listeners to a node
  in the tree at document level is done using WO.Update messages
  as described in Section 4.1, while at the programming level is
  done using WO.Selector messages as described in Section 4.3.

By

  The Widex Framework enables event listeners to be attached
  to DOM nodes using either WO.Update messages as described in
  Section 4.1, or through WO.Selector messages as described in
  Section 4.3.

Which avoids the use of "programming" vs "document level".

However, this leaves open the issue of how to distinguish
local and remote event listeners. The DOM EventTarget interface
only deals with local event handlers. XML Events allows you
to specify handlers via URIs but the assumption seems to be
that these are scripts that are downloaded and executed locally
by the markup language interpreter.

It seems to me that WO.Update messages can only be used to add local 
event listeners, unless there is specific provision for remote event 
listeners in the markup language itself. Remote event listeners can 
be added by WO.Selector messages, or as part of session 
establishment, or by prior arrangement.

I would therefore like to propose that we discard the text:

  DOM model describes mainly two ways to associate an event
  listener to a node in the tree:

  1.  at the programming level, using the EventTarget interface as
      specified by DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413]
      or a method specific to the UI markup language.
  2.  at the document level, using XML Events
      [W3C.REC-xml-events-20031014] or an ad-hoc syntax, as the
      ones provided by the UI markup language itself, e.g.  XHTML
      [W3C.REC-xhtml1-20020801] or SVG 1.1 [W3C.REC-SVG11-20030114].

The text following figure 2 would then be:

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

  o  prior agreement between the Widex Renderer and Widex Server

  o  a list of events passed during session establishment

  o  the Widex Server could direct the Widex Renderer to add
     and remove event listeners during the session

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

I suggest we add something about how the MVC pattern allows
server-side operations on the DOM to be reflected to the
Widex Renderer as a way of helping to address the concerns
over the terminology of DOM Mutation events.

How about:

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

  In a little more detail, changes made by the Widex Server
  to the XML DOM for the 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.

We can take up the terminological issue of events versus
actions in the REX specification. I don't think we need
to cover that in Widex where we seem have consensus on
the three kinds of messages (Update, Event, and Selector).

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

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

---

From: Dave Raggett <[email-masked]>
Date: Wed, 14 Jun 2006 12:54:51 +0100 (BST)

I forgot to cover changes to section 4.3:

I suggest replacing:

  The WO.Selector message MUST contain information about the
  event listeners associated to a node in the tree at the
  programming level only.

By:

  The WO.Selector message MUST contain sufficient information
  to enable the Widex Renderer to add or remove remote event
  listeners associated with particular nodes in the XML DOM.

---

From: "Jin Yu" <[email-masked]>
Date: Wed, 14 Jun 2006 18:59:51 -0700

> Which avoids the use of "programming" vs "document level".

Just want to clarify - later on you proposed to remove this paragraph (#1 and
#2), so the above replacement wouldn't be used anyway?

> by the markup language interpreter.

Yes, DOM EventTarget was not designed with remote events in mind. So that's why
in one of my previous mails I was saying it would be useful for us only in the
case when it operates on the server-side virtual DOM and then the calls in turn
get serialized into WO.Selector messages.

As for XML Events, you are right. I think implicitly the resource pointed to by
the handler attribute is to be downloaded and executed in the renderer side.
Perhaps, we can suggest some new wording or syntax for the handler attribute?
Actually, all we need is a magic value *remote*, so the renderer knows to send
the event to the server rather than handle it locally. 

> establishment, or by prior arrangement.

I think it's good to clearly distinguish local and remote event listeners.
However, technically speaking, WO.Update messages could be used to update remote
event listeners if the UI language has the explicit support for the notion of
remote events. Similarly, there is no reason why WO.Selector can't be used to
update local listeners.

On the other hand, currently there is no UI language having explicit support for
remote event listeners. So I'm ok with saying that WO.Update messages are to be
used for managing local listeners only. But some explanation is needed to inform
our readers of the rationales behind this design.

We may also want to say something about the behavior of multiple event listeners
(a mix of local and remote listeners) for the same event. For example, in XUP,
if a local listener can fully handle an event locally, it can prevent a remote
listener from being called.

>   where these changes are mediated by WO.Selector messages.

Yes, I think this is a good explanatory text.

>   whether the Widex Server has an explicit or a virtual

I think this is more like an implementation suggestion (i.e. using DOM mutation
events on the server side). There are other implementation techniques for the
server to trace and serialize the UI updates. For example, in the OpenXUP
server, we don't use DOM events at all for performance reasons. The server has a
UI tracker, which tracks every API calls to the UI tree; and at the end of the
request processing, the content of the UI tracker is serialized into UI updates
and sent to the client.

> the three kinds of messages (Update, Event, and Selector).

Yes, Widex's terminology is fine. My problems are with REX ...

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org

---

From: Dave Raggett <[email-masked]>
Date: Thu, 15 Jun 2006 09:51:14 +0100 (BST)

On Wed, 14 Jun 2006, Jin Yu wrote:

> Just want to clarify - later on you proposed to remove this 
> paragraph (#1 and #2), so the above replacement wouldn't be used 
> anyway?

Correct.

> We may also want to say something about the behavior of multiple 
> event listeners (a mix of local and remote listeners) for the same 
> event. For example, in XUP, if a local listener can fully handle 
> an event locally, it can prevent a remote listener from being 
> called.

I think that comes down to the processing model for events. In the 
case of DOM events, there is provision to stop propagation and to
prevent the default handler from being invoked. It is therefore a
matter of where the remote event listener is attached. A local
handler could then prevent the remote event listener from being
invoked. The otherway round is more complicated. The stub used
in the Widex Renderer could stop further propagation, but there
would be undue latency to allow the corresponding handler in the
Widex Server to be able to do so.

We could include some text on this in the Widex Framework draft,
but is it really necessary? It seems like being at a different
level of detail.

> I think this is more like an implementation suggestion (i.e.
> using DOM mutation events on the server side). There are other 
> implementation techniques for the server to trace and serialize 
> the UI updates. For example, in the OpenXUP server, we don't use 
> DOM events at all for performance reasons. The server has a UI 
> tracker, which tracks every API calls to the UI tree; and at the 
> end of the request processing, the content of the UI tracker is 
> serialized into UI updates and sent to the client.

Agreed, but what should we say if anything in the Widex Framework
draft?

> Yes, Widex's terminology is fine. My problems are with REX ...

Fine, I will see what can be done to resolve that in the W3C
work.

---

From: "Jin Yu" <[email-masked]>
Date: Thu, 15 Jun 2006 19:55:18 -0700

> but is it really necessary? It seems like being at a different

I think it would be nice to have some text explaining how remote events and
listeners relate to (or work with) DOM's event model. Something along the line
you wrote above seems to be very reasonable.

> Agreed, but what should we say if anything in the Widex Framework

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.

Regards,

Jin

---

From: Dave Raggett <[email-masked]>
Date: Fri, 16 Jun 2006 09:45:16 +0100 (BST)

On Thu, 15 Jun 2006, Jin Yu wrote:

>>> event listeners (a mix of local and remote listeners) for the 
>>> same event. For example, in XUP, if a local listener can fully 
>>> handle an event locally, it can prevent a remote listener from 
>>> being called.
>>
> I think it would be nice to have some text explaining how remote 
> events and listeners relate to (or work with) DOM's event model. 
> Something along the line you wrote above seems to be very 
> reasonable.

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.

> 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.

Regards,

---

From: <[email-masked]>
Date: Fri, 16 Jun 2006 11:57:04 +0300

Hi Jin, 

>
>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.
>
>Regards,
>
>Jin

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.

Vlad

---

From: "Jin Yu" <[email-masked]>
Date: Fri, 16 Jun 2006 06:46:46 -0700

> the stopPropagation method on DOM events.

Sounds good.

>   whether the Widex Server has an explicit or a virtual

Sorry but I'm still a bit confused about the meaning of "explicit view", after

> 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

---

From: Dave Raggett <[email-masked]>
Date: Fri, 16 Jun 2006 17:14:16 +0100 (BST)

On Fri, 16 Jun 2006, Jin Yu wrote:

> 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:
>

Vlad writes:

>> 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.

Jin responds:

> 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.

I believe that whether or not the Widex Server maintains an
explicit in-memory XML DOM tree for the View is implementation
dependent and shouldn't effect the Widex protocol. If this is
just a question of wording, will the following work for you?

  View, that is, an in-memory XML DOM tree, as this is
  an implementation dependent design choice.

Regards,

---

From: "Jin Yu" <[email-masked]>
Date: Fri, 16 Jun 2006 16:42:59 -0700

>   an implementation dependent design choice.

I think I got it. I see there are three ways for the server to maintain the
view:

1. the server maintains an in-memory copy of the XML DOM representing the view
on the renderer side.

2. the server could use some more efficient data structure, e.g. a UI tree or
graph to represent the view on the renderer side.

3. the server could represent the view as a string or binary blob. That's the
case for HTML page-based applications today. But the drawback is the WO.Update
messages will always contain full page updates, not incremental updates.

Do you call #1 explicit view and #2 and #3 virtual view? For me, I'd call all
three cases virtual view, since the physical view (the rendering) is only at the
renderer side and the server only keeps the data model that represents the view.
So I'd refer to #1 as something like "explicit DOM" rather than "explicit view".

Regards,

Jin

---

From: <[email-masked]>
Date: Sat, 17 Jun 2006 15:14:27 +0300

Hi,

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

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

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

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

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

   With the DOM Event model it is possible to attach multiple event
   listeners for the same event.  The DOM event model defines an
   ordering in which the listeners are invoked, and provides a means to
   stop further propagation of the event, and to prevent the default
   event handler from being invoked.  In the case of a mix of local and
   remote event listeners, depending on where they are attached, a local
   event listener could stop further propagation and thereby prevent the
   remote event listener from being invoked.  The other way around is
   more complicated.  The stub used by the Widex Renderer for remote
   event listeners could itself stop further propagation, but there
   would be undue latency incurred if this was to be done by the
   corresponding event handler in the Widex Server.

   In an implementation where the Widex Server maintains an explicit XML
   DOM for the View, changes made by the Widex Server to this View
   result in DOM events, e.g.  DOM Mutation events.  The Widex Framework
   in the server (as shown in Figure 1) can listen for these events to
   generate the corresponding Widex messages.  The Widex Framework in
   the Renderer interprets these messages to reflect the changes to its
   copy of the XML DOM for the View.  Note that the Widex messages are
   independent of whether the Widex Server has an explicit or a virtual
   View, that is, an in-memory XML DOM tree, as this is an
   implementation dependent design choice.

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

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

Vlad

---

From: "Jin Yu" <[email-masked]>
Date: Sun, 18 Jun 2006 18:11:32 -0700

>       event listeners during the session

For the second bullet, I prefer "a list of messages..." rather than "a list of
events...". The word "event" is overloaded here; I don't think it refers to "UI
event", which is used predominantly in rest of the text.

>    implementation dependent design choice.

Perhaps we can rephrase the last sentence as:

"Note that the Widex messages are independent of whether the Widex Server
maintains an explicit DOM for the View, that is, an in-memory XML DOM tree, as
this is an implementation dependent design choice."

Regards,

Jin

---

From: <[email-masked]>
Date: Mon, 19 Jun 2006 10:49:26 +0300

>-----Original Message-----
>From: ext Jin Yu [mailto:[email-masked]] 
>Sent: 19 June, 2006 04:12
>To: Stirbu Vlad (Nokia-TP-MSW/Tampere); [email-masked]
>Cc: [email-masked]
>Subject: RE: [Widex] Proposed rewording for Framework draft
>

>For the second bullet, I prefer "a list of messages..." rather 
>than "a list of events...". The word "event" is overloaded 
>here; I don't think it refers to "UI event", which is used 
>predominantly in rest of the text.
>

I think that the meaning of this bullet is that you get the list of
events that have remote scope using the service discovery and session
setup component of the framework. They are exchanged according to the
particular mechanism and they will not be defined in this WG, e.g. as
WOs. For this reason, I tend to think that using the term messages is
confusing.

Vlad

---

From: "Jin Yu" <[email-masked]>
Date: Mon, 19 Jun 2006 06:46:20 -0700

> WOs. For this reason, I tend to think that using the term messages is

I agree that this bullet won't be defined by this WG. But the term "event" is
even more confusing since it's already overloaded. So what's a better term?

Regards,

Jin

---

From: Dave Raggett <[email-masked]>
Date: Mon, 19 Jun 2006 15:16:30 +0100 (BST)

On Mon, 19 Jun 2006, Jin Yu wrote:

> I agree that this bullet won't be defined by this WG. But the term 
> "event" is even more confusing since it's already overloaded. So 
> what's a better term?

The bullet point needs to be read in the context of the preceding 
paragraph:

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

This I believe makes it pretty clear that what is being discussed 
are events that are raised in the Windex Renderer and which need to 
be forwarded to the Widex Server as WO.Event messages. The bullet 
point suggests that one way for the Widex Server to indicate which 
such events it is interested in is via a list of events that is 
exchanged with the Widex Renderer at session establishment. Widex 
won't define the events, but it is within our scope to define a 
mechanism for passing a list of event names as part of session 
establishment for a binding to specific protocol. This is something
we can now start talking about in more detail, but it would be
good to first reach agreement on publishing the framework draft.

---

From: "Jin Yu" <[email-masked]>
Date: Mon, 19 Jun 2006 19:55:02 -0700

> good to first reach agreement on publishing the framework draft.

Ok, I see, the word "event" here indeed means "UI event". But it's not really
sending event, as in the WO.Event messages. Here, we are talking about
exchanging a list of event names. So maybe change it to "a list of event names"?

Regards,

Jin

---

From: Dave Raggett <[email-masked]>
Date: Tue, 20 Jun 2006 09:42:08 +0100 (BST)

On Mon, 19 Jun 2006, Jin Yu wrote:

> Ok, I see, the word "event" here indeed means "UI event". But it's 
> not really sending event, as in the WO.Event messages. Here, we 
> are talking about exchanging a list of event names. So maybe 
> change it to "a list of event names"?

Yes, saying "event names" would be fine.

---

From: Rosfran Lins Borges <[email-masked]>
Date: Wed, 21 Jun 2006 21:10:25 -0300

After reading all the recent discussions, and reviewing again the 
Widex framework draft, I would like to suggest a better rephrasing to 
the last paragraph from section 4.2:

"4.2.  WO.Event Message

    The WO.Event messages are primarily used to carry events triggered on
  (...)
    interface.

    Note: Some UI markup languages, e.g.  Glade [1], do not have events
    defined at document level and therefore WO.Event messages MUST be
    able to serialize the events emitted by the associated libraries,
    e.g.  GTK+ [2]."

Would changes to:

    "Note: Some UI markup languages, e.g.  Glade [1], which are 
originally designed for only working with standalone UI architectures 
(i.e., that doesn't implements a networked MVC, where we have a 
change-propagation mechanism that ensures consistency between 
remotelly-located user interface and model), and do not have a defined 
syntax for event modeling (at least, not at document level), this kind 
of UI event was not originally made to be carried as a string of bits 
through the network. So, when using Widex with these applications, the 
WO.Event messages MUST be able to serialize the events (where "events" 
would means "GTK+ signals") emitted by its associated UI libraries, e.g. 
GTK+ [2]."

-- 
Rosfran Borges

---

From: Dave Raggett <[email-masked]>
Date: Thu, 22 Jun 2006 17:01:41 +0100 (BST)

On Wed, 21 Jun 2006, Rosfran Lins Borges wrote:

>
>    After reading all the recent discussions, and reviewing again the Widex 
> framework draft, I would like to suggest a better rephrasing to the last 
> paragraph from section 4.2:
>
> "4.2.  WO.Event Message
>
> originally designed for only working with standalone UI 
> architectures (i.e., that doesn't implements a networked MVC, 
> where we have a change-propagation mechanism that ensures 
> consistency between remotelly-located user interface and model), 
> and do not have a defined syntax for event modeling (at least, not 
> at document level), this kind of UI event was not originally made 
> to be carried as a string of bits through the network. So, when 
> using Widex with these applications, the WO.Event messages MUST be 
> able to serialize the events (where "events" would means "GTK+ 
> signals") emitted by its associated UI libraries, e.g. GTK+ [2]."

I think I get your intention, but the wording you suggest is a 
little hard to read with all the bracketed clauses.

---

From: Rosfran Lins Borges <[email-masked]>
Date: Fri, 23 Jun 2006 10:45:35 -0300

Maybe I'm worried too much, because I had been supposing a reader of 
this draft that may possibly knows nothing about Glade XML schema and/or 
GTK+ "signals and slots" event model. I hope it is more concise now:

    "Note: Some UI markup languages, e.g.  Glade [1], which are designed 
only for standalone UI architectures (e.g., doesn't have a 
change-propagation mechanism, defined at document level, which ensures 
consistency between remotelly-located user interface and model), 
originally cannot sends these UI events as a string of bits through the 
network. So, when using Widex with this kind of UI event model, the 
WO.Event messages MUST be able to serialize the events (e.g. GTK+ 
signals) emitted by its associated UI libraries, e.g. GTK+ [2]."

--
Rosfran Borges

ext Dave Raggett wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>> would means "GTK+ signals") emitted by its associated UI libraries, 
>> e.g. GTK+ [2]."
> 
> 
> I think I get your intention, but the wording you suggest is a little 
> hard to read with all the bracketed clauses.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFEmr7qb3AdEmxAsUsRAqsEAJ9WU+KwFjFq+cLrY59+i53E2IAAZQCfUtnF
> hlUOBG1uimF4fN6efqFTGjk=
> =LTdT
> -----END PGP SIGNATURE-----

---

From: Dave Raggett <[email-masked]>
Date: Fri, 23 Jun 2006 18:07:12 +0100 (BST)

On Fri, 23 Jun 2006, Rosfran Lins Borges wrote:

>  Maybe I'm worried too much, because I had been supposing a reader 
> of this draft that may possibly knows nothing about Glade XML 
> schema and/or GTK+ "signals and slots" event model. I hope it is 
> more concise now:
>
> designed only for standalone UI architectures (e.g., doesn't have 
> a change-propagation mechanism, defined at document level, which 
> ensures consistency between remotelly-located user interface and 
> model), originally cannot sends these UI events as a string of 
> bits through the network. So, when using Widex with this kind of 
> UI event model, the WO.Event messages MUST be able to serialize 
> the events (e.g. GTK+ signals) emitted by its associated UI 
> libraries, e.g. GTK+ [2]."

Although I am a native English speaker, I still have difficulty
in understanding the above. Here is my attempt to explain this
based upon reading the web pages describing GLADE:

  Note: some UI markup languages don't make use of XML DOM events.
  An example is Glade [1], which is a user interface builder for
  GTK+ [2]. Glade generates XML files that describe the user
  interface. These files are interpreted by libGlade [3] to build
  the user interface at runtime. To use Glade and GTK+ with Widex,
  the WO.Event messages MUST be able to  serialize the GTK+ signals
  that act as UI events, and which are raised by the associated
  GTK+ UI libraries.

[1] http://glade.gnome.org/
[2] http://www.gtk.org/
[3] http://www.jamesh.id.au/software/libglade/

---

From: Rosfran Lins Borges <[email-masked]>
Date: Wed, 28 Jun 2006 20:35:54 -0300

It's a lot cleaner and concise now, you really got the idea on my 
unsuccessfull GTK+ and Glade explanations! Thanks for the good input...

-- 
Rosfran Borges

ext Dave Raggett wrote:
>> this draft that may possibly knows nothing about Glade XML schema 
>> and/or GTK+ "signals and slots" event model. I hope it is more concise 
>> now:
>>
>> originally cannot sends these UI events as a string of bits through 
>> the network. So, when using Widex with this kind of UI event model, 
>> the WO.Event messages MUST be able to serialize the events (e.g. GTK+ 
> iD8DBQFEnB/Hb3AdEmxAsUsRAlWSAJ9QZqLsLEIDIJox0rPGoHNYorZBTQCfUzl5
> 0einBkIkprtQs2JB4ZUZ9Po=
> =5GhN