Re: incremental delay considered harmful

 Hi W3C form group members !!!
 May be its an extra thing in the current discussion about the delay
attribute .. Better we can add additional  attribute called "interval" and
the values are none or some milliseconds depends on the application
requirement ...

By

Rajamani M
Chennai
cell: 9791125383


On Wed, Mar 30, 2011 at 1:35 AM, COUTHURES Alain <
alain.couthures@agencexml.com> wrote:

>  Nick,
>
> The problem with a calculation is that it has to be performed for each
> control and that it has to be initialized with a quite small value because
> most actions will be rapidly executed. So, for the obviously (but just for
> the author) time consuming actions, the first keystroke will always launch
> them with a too small delay.
>
> Having different XY values or different delay values for different devices
> is surely a problem because a browser cannot say much about the device in
> which it is running. The author, again, has to test the form on various
> devices to adjust values.
>
> Maybe it would be good enough to allow something like delay="yes" so a
> configured initial delay could be used and implementations could try to
> optimize it the way they want. The performance of the device could also be
> measured to adapt the initial delay.
>
> What do you think?
>
> Thanks!
>
> -Alain
>
> Le 29/03/2011 10:57, Nick Van den Bleeken a écrit :
>
>  Alain,
>
>
>
> To me it still feels that the delay should be something the XForms
> processor should ‘calculate’ himself ideally without any specific attributes
> on the control because:
>
> ·         The form author shouldn’t have to worry about what the best
> value for the delay is
>
> ·         May depend on the device on which the form is ran
>
> ·         May depend the XForms processor (pure client based or
> client/server based)
>
> ·         May even vary on load and or version of the external service
> that is called
>
>
>
> I’m not saying that an XForms implementation couldn’t have configuration
> parameters (or even a processor specific attribute on the control or form if
> really desired) that can be used to ‘calculate’ the optimal value for delays
> between xforms-value-change events.
>
>
>
> The implementation is more suited for doing the calculation because it
> could for example take into account the time needed to process previous
> xforms-value-change events, and or don’t dispatch a new xforms-value-change
> event until all processing of the previous event is done (also asynchronous
> submissions -> this should already the case I think because ‘Under no
> circumstances can more than a single concurrent submit process be under way
> for a particular XForms submission’).
>
>
>
> Kind regards,
>
> Nick Van den Bleeken
>
> R&D Manager
>
> Phone: +32 3 821 01 70
>
> Office fax: +32 3 821 01 71
>
> nick.van.den.bleeken@inventivegroup.com
>
> www.inventivedesigners.com
>
>
>