W3C home > Mailing lists > Public > www-forms@w3.org > March 2011

Re: incremental delay considered harmful

From: Joern Turner <joern.turner@googlemail.com>
Date: Wed, 30 Mar 2011 10:52:13 +0200
Message-ID: <AANLkTi=HQvtxiUNe3qrd26R0Qxt0skcm=gTu4Dye9XLg@mail.gmail.com>
To: "Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>
Cc: public-forms@w3.org, www-forms@w3.org
Hi,

On Wed, Mar 23, 2011 at 6:32 PM, Leigh L. Klotz, Jr.
<Leigh.Klotz@xerox.com> wrote:
> [This is in response to ACTION-1786:
> http://www.w3.org/2011/03/23-forms-minutes.html#action02 ]
>
> At least two XForms Processor implementations have added @delay to form
> controls, and use it to control how frequently @incremental=true controls
> dispatch xforms-value-changed events.
Right - betterFORM also has a such a delay attribute.

>
> We've discussed a proposal to add this to XForms 1.2 three times, and each
> time have come to the conclusion that it is unnecessary.  However, we've
> decided to write up a set of use cases and how we believe they are already
> answered by XForms 1.1 facilities.  If you believe that the use cases aren't
> answered, or if there are other significant use cases, please let us know.
> If you believe the implementation techniques described below are incorrect
> or too difficult, please let us know.  Otherwise we'll assume that there is
> no need to add @delay to form controls, and that implementations will
> eventually drop the extension in favor of the techniques similar to those
> described below, or other techniques which preserve system performance
> without requiring form authors to use non-interoperable extensions.
>
> XForms processor vendors might choose to provide implementation of
> customizing the behavior of incremental, but the default behavior should be
> one of reasonable performance, and should not result in an immediate
> dispatch of xforms-value-changed for every keystroke.
Agree - the default behavior should work for the user.

Though i do not see a special reason why it is considered harmful to
dispatch xforms-value-changed for every keystroke. As XForms is
device- and platform-independent it might very well work for an
implementation to do so as the device maybe not even use a network
connection - this at least is the only reason i can see - that there
is a worry that firing events too often causes a lot of requests over
the network. So, if i'm not overseeing something it is mainly a matter
of performance of the implementation. I'm not sure if i'd like to see
(in lack of a better term) 'performance  policies' in a spec.

Of course it's a main interest of an implementer to provide a solution
with reasonable performance for the user - otherwise it's not very
likely that many people will use this implementation. How this is
achieved is a complete different matter and implementers should not be
constrained in their approach IMO. E.g. if an implementation uses a
socket connection (lets say CometD) then it can perform very well and
does not necessarily cause a lot of requests (as just one connection
is used) or perform badly due to the amount of events. If so, an
implementer will change this in his/her own interest.

So, agree that the default should work but i still think that there
are situations where you need this kind of fine-tuning as an author -
one obvious indicator for this fact is that at least 2 (3?) XForms
have added this as a feature. For the sake of interoperability it may
make sense to allow an attribute like @delay however it will be named
(that's just syntax).

>
> Use case: server-side completion
> input/@incremental='true' is used with an xforms-value-changed event handler
> which dispatches send to an asynchronous submission.  Submission responses
> are used to update the itemset of an accompanying xf:select1.  If the user
> types too fast and the asynchronous submission takes too long, or if
> pre-submission processing takes too long, system performance may suffer.
> @delay='200' might offer a time interval for dispatch of
> xforms-value-changed events.
>
> Use case: xslt transformation
> input/@incremental='true' is used with an xforms-value-changed event handler
> which dispatches an event to cause an XSLT transformation to take place.  If
> the user types too fast and the XSLT transformation takes a long time,
> system performance may suffer.  @delay='200' might offer a time interval for
> dispatch of xforms-value-changed events.
This kind of confuses me - these use cases seem to argue for a @delay attribute?

>
> XForms 1.1:
> XForms 1.1 does not require that xforms-value-changed be dispatched on every
> keystroke.  (In fact there might not even be keystrokes, depending on the
> user interface medium.)
Fully agree - it does not need to dispatch on every keystroke but why
shouldn't it be allowed to do so if that's appropriate for the device
or platform?

And of course it does not need to be a keystroke - it also may be a
person speaking a work letter by letter in a phone app. But
implementations are typically more or less constrained or tied to
certain platforms and have to use the mechanisms of the platform - in
one case these are keystrokes in another maybe 'speech events'.
>
> Discussion of Implementation Techniques:
>
> Erik Bruchez points out that Orbeon offers a simple heurstic-based approach
> for how often input/@incremental dispatches xforms-value-changed in a
> desktop user interface:  Each time the user types a character, if an
> xforms-value-changed event has been dispatched more recently than X
> milliseconds, do not dispatch the event, otherwise do dispatch the event.
> If the user stops typing for more than Y milliseconds, dispatch the event.
> The numbers X and Y should be determined by the XForms Processor itself
> based on its own performance metrics.
>
> XForms processor vendors might choose to provide implementation specific
> ways of setting X and Y parameters, but the default behavior should be one
> of reasonable performance, and not an immediate dispatch of
> xforms-value-changed for every keystroke.  Given that there are at least two
> delays to be customized, re-using the XForms @delay attribute for the
> vendor-specific extension seems like it should be avoided.
I have to confess that i'm kind of confused where the WG is heading
here - on the one hand the use of @delay seem to be considered harmful
but XForms processors might still choose to do so ?

Again - i fully understand and agree that the default behavior for
incremental should give the user a reasonable performance. The whole
idea of @delay is one of an optimization for situations that are
uncommon (at least we see it like that and i'm quite sure that no
vendor really enforces that attribute or otherwise perform badly).

The fact that several processors have added this feature is IMO an
indicator that such a facility is needed in some rare situations. For
the sake of interoperability it would be good if the facility could be
expressed in standardized markup.

Joern

> Discussion of Authoring Techniques:
> Form authors need not dispatch a submission or perform an XSLT
> transformation for every xforms-value-changed event, either.
> See http://www.w3.org/MarkUp/Forms/wiki/Submission_Request-Response_IDs for
> one consideration for throttling submission.
> Do we need something more general here?
>
> Leigh.
>
>
>
>
>
>
>
>
>
Received on Wednesday, 30 March 2011 08:52:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:22 GMT