Proposal: High resolution (and otherwise improved) timer API

[Maciej Stachowiak]

Hello Web Apps WG,

A number of WebKit developers (including from the Chrome team and the  
Safari team) have been discussing ideas for a new and improved timer  
API. We would like to serve the following use cases which we feel are  
not well served by the de facto standard (and now HTML5 standard)  
interfaces of setTimeout and setInterval:


1) True zero-delay timers, to be used to break up long-running  
computations so they can return to the event loop before they  
continue, with minimal additional delay. In most browsers, setTimeout  
and setInterval have an implied minimum timeout of 10ms or 15.6ms,  
meaning they introduce significant delay when used for such purposes.


2) High-resolution timers to be used to precisely drive animations,  
with an easy way to account for timer jitter; a high-resolution timer  
would try to achieve a 60fps frame rate by firing more than 60 times a  
second and drawing the next frame on the cycle closest to the desired  
paint time. Again, more precision than 10-15.6ms is needed here.


3) Long-lasting timers that may need to have their pending duration  
changed before they fire.



We studied the SVGTimer API from SVG Tiny 1.2, and we believe that  
interface is not suitable either, because it makes the simple code for  
case 1 be three lines instead of one, without adding meaningful extra  
benefit in exchange. Here is a rough outline of our proposal:



// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,  
in TimerHandler handler);

}

// starts a timer that will fire in "delayInSeconds" seconds;  
"delayInSeconds" may be fractional, and resolution down to at least  
milliseconds should be provided, but user agents may provide even  
smaller resolution. If delayInSeconds is 0, then the timer should be  
considered ready to fire immediately on the next return to the event  
loop. If repeating is true, the timer will fire indefinitely every  
"delayInSeconds" seconds, until stopped. When the timer fires,  
handler's "handleTimer" method is called with the timer object as an  
argument.


interface Timer {
void stop(); // stops the timer, if it still has not fired or if  
it is repeating; maybe this should be called "cancel()"


readonly attribute double timeElapsed; // time in seconds since  
the timer was started or since the last time it fired if repeating and  
it has already fired at least once


void restart([Variadic] in double newDelay);
// if the timer is running it is stopped; then it is restarted  
with newDelay as its delay, or the existing delay if newDelay is  
omitted; the repeating status

// and callback will remain the same.
}

[NativeObject] interface TimerHandler {
void handleTimer(in Timer timer);
}


I think we should put this design or something much like it in a new  
standalone spec, possibly also taking on the legacy setTimeout/ 
setInterval interfaces.


Possible variations discussed:

- Perhaps the delay should be in possibly-fractional milliseconds  
rather than possibly-fractional seconds. But expressing microseconds  
as fractional milliseconds seems quite weird.


- Perhaps the argument order should be (handler, delay, repeating)  
instead, to be more like setTimeout / setInterval


- Perhaps the "repeating" or even the "delayInSeconds" arguments  
should be optional, defaulting to false and 0 respectively, and  
possibly in combination with the above suggestion.


- Perhaps there should be separate startTimer and startRepeatingTimer  
functions.



I will also note that this interface does not attempt to be fully  
general; there's no provision for inspecting a timer's callback  
function, for making the first delay be different than the repeat  
delay, for making the timer repeat but only a finite number of times,  
or anything like that. These did not seem like common enough cases to  
warrant bloating the API.



Regards,
Maciej

Comments on some Web IDL extended attribute names

[Maciej Stachowiak]

I think [NativeObject] should be renamed to [Callback]. It is meant to  
be used for callback objects that have a single designated callback  
method, right?


I think [Variadic] should be renamed [Optional]. A function may be  
variadic, but a parameter is optional, and this goes on the parameter.


Regards,
Maciej

[widgets] Minutes from 2 October 2008 Voice Conference

[Arthur Barstow]

The minutes from the October 2 Widgets f2f meeting are available at  
the following and copied below:


 

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before October 9 (next Widgets  
voice conference); otherwise these minutes will be considered approved.


-Regards, Art Barstow

   [1]W3C

  [1] http://www.w3.org/

   - DRAFT -

   Widgets Voice Conference
  02 Oct 2008

   [2]Agenda

  [2] http://lists.w3.org/Archives/Public/public-webapps/ 
2008OctDec/0001.html


   See also: [3]IRC log

  [3] http://www.w3.org/2008/10/02-wam-irc

Attendees

   Present
  Art, Marcos, Mark, David, Adam, Arve, Claudio, Benoit, Josh,
  MikeSmith

   Regrets
  Thomas, Nick

   Chair
  ArtB

   Scribe
  Art

Contents

 * [4]Topics
 1. [5]Agenda tweaks
 2. [6]Annoucements
 3. [7]Widgets Core API and Event spec
 4. [8]Preferences API
 5. [9]P&C feature element and access element
 6. [10]P&C  element
 7. [11]Dig Sig spec
 * [12]Summary of Action Items
 _



sorry, will call in in 15 seconds

s the meeting number

Scribe: Art

ScribeNick: ArtB

   Date: 2 October 2008

Agenda tweaks

   AB: any change requests?

   [None]

Annoucements

   AB: registration deadline for Mandelieu is now Oct 12
   ... Mandelieu agenda is still a WIP
   ... Security WS in December

   MC: I intend to submit a Position Paper

   AB: pub moratorium is Oct 13

Widgets Core API and Event spec

   AB: what's the status Arve?

   Arve: I just committed a new version to CVS
   ... [13]http://dev.w3.org/2006/waf/widgets-api/
   ... we need to talk about using HTML5 APIs instead of get/set prefs
   ... does the refs section need to be complete?

 [13] http://dev.w3.org/2006/waf/widgets-api/

   MC: I think you can leave it open

[14]http://dev.w3.org/2006/waf/widgets-api/Overview.src.html

 [14] http://dev.w3.org/2006/waf/widgets-api/Overview.src.html

   AB: anything else blocking pub?
   ... may want to provide a bit more context for the red blocks

   BS: I agree

   Arve: yes, I can do that

   BS: a list of issues would be helpful; gives the reader a sense of
   what's going to be done

Preferences API

   AB: Marcos made a propsal on the list
   [15]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/
   0736.html

 [15] http://lists.w3.org/Archives/Public/public-webapps/ 
2008JulSep/


   
   [16]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/07
   36.html

 [16] http://lists.w3.org/Archives/Public/public-webapps/ 
2008JulSep/0736.html


   JS: I like the idea of dropping the APIs and using HTML5

+1

   MC: the basic problem is we are defining an API that is already
   defined in HTML5
   ... this will cause probs for developers
   ... we don't want to have two different APIs
   ... I recommend we use HTML5
   ... It has already been implemented in some browsers

   Arve: I quite agree with Marcos
   ... but we need to mention some stuff
   ... if we are going to do that
   ... For example, need to make it clear each widget instance has its
   own cache

   MC: agree we may need to do some tweaks
   ... need to understand the overlaps of our reqs with HTML5

   Arve: need to add some explicit requirements for the UA
   ... we may need to define a UA context
   ... that says something about caching, redirects, etc.
   ... Stuff that is beyond the scope of HTML5
   ... The interface is defined in HTML5 but not the implications in
   our context

   JS: regarding reqs, need to also think about the need for storage to
   grow

We need to define: Widget instance caching context, widget
   instance security context, widget instance storage context

   AB: where would this stuff be documented?

   Arve: in the P&C spec

   MC: I'm fine with that

   AB: agree this contextual info would be good to document
   ... but who is going to create that documentation?
   ... does Opera have some documentation we could review?

   Arve: another option is to go back to Opera's security input and
   move it forward

what we're saying currently is:

Separate widget instances share no information at all.
   Specifically:

   MC: yes, maybe this information should not in P&C but rather in a
   separarte doc such as Widgets Sec Model

A cookie set by a widget instance, or by a URL loaded by a
   widget (eg through XmlHttpRequest) is visible only to that widget
   instance, never to any other instances or to documents loaded into
   the browser in any other way.

If a URL loaded by a widget requires HTTP authentication then
   authentication must be performed on behalf of that widget instance;
   the authentication is not shared wi