Re: [Widex] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.txt

["Jin Yu" <[e-mail]>]

Hi all,

I have a few comments about the requirements draft, mostly based on my
experience in working on XUP and X11.

* Event Selection

In a networked UI environment, efficient event delivery is as important as
updating the UI itself. The requirements document already discussed that
certain events can be handled locally at the renderer (e.g. a mouse click on
a menu bar will display a submenu) and therefore there is no need to send
those events to the server. However, in addition to that, it is very
important that the renderer only sends events that are *interested* by the
application logic on the server side. For example, typing in a text field
generates a key press event for each key stroke. But the application may not
care about each key stoke; it only wants to receive the entire text when the
user clicks on a button labeled "submit". In this case, the application is
interested in the mouse click event on the "submit" button, but not
interested in the key press events in the text field.

So what's needed is an event selection mechanism, and I believe this is
needed at the protocol level, not at the XML UI language level. That is,
this event selection mechanism should be independent of the actual UI
language in use.

I think we could define a new type of message - widex event selection
object. This is a one directional message that goes from the server to the
renderer, allowing the application to instruct the renderer to send only
selected events. The widex event selection object would specify the type of
event as well as the UI component that fired the event. And the event type
would be a namespace-qualified event from any concrete XML UI languages (not
limited by DOM events; it could come from XUL, XAML, etc.)

Note that the new event selection object would be very different from
WO.Event. The event selection object specifies the event delivery criteria;
whereas WO.Event specifies the actual event fired, with timestamp, etc.

Similar design can be found in XUP, where it has the notion of "event
selectors" (<http://www.openxup.org/TR/xup/#elem_selector>).

In addition, X11 also allows the selection of events, via the library
function XSelectInput().

* UI State Synchronization

The diagram at the beginning of section 2 shows the UI update interface as
one way messages from the server to the renderer. However, for the UI state
to be synchronized, the renderer should also send UI update messages to the
server.

The server-side UI state is manipulated by application code (e.g. create a
new window, change background color of a label, etc.); this results server
to renderer UI updates messages.

On the other hand, the renderer's UI state is manipulated by the end user.
For example, when the user is typing text in a text field, the UI state of
that field is getting changed. This change needs to be synchronized to the
server. Other examples include resizing a window, checking a check box, etc.
Note that the synchronization needs not to be immediate, as the application
may just care about the entire text input, not each key stoke. But how and
when to synchronize should be left to the application to decide. Again, this
could be done by using the widex event selection object proposed above.


Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


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