Re: ISSUE-70: what to do about window timers?

On Apr 6, 2006, at 6:30 AM, Robin Berjon wrote:

>
> On Apr 06, 2006, at 02:03, Ian Hickson wrote:
>> On Wed, 5 Apr 2006, Robin Berjon wrote:
>>> The reason a timer interface was developed the SVG WG was in  
>>> response to
>>> such requests, so I'd say there's a call for it.
>>
>> No offence, but based on SVG 1.2, the SVG group considers the  
>> slightest
>> hint of a request as being strong industry demand. I wouldn't  
>> consider the
>> SVG group adding a feature in response to requests to be evidence  
>> that
>> there are enough requests to justify adding a feature to our specs.
>
> None taken, but implying the contrary isn't exactly overly helpful  
> either. As we can see from this thread there are indeed good  
> reasons to have one such API.
>
> I'll take a stab at putting a draft up in the month to come.

Is there any reason this should be in a separate spec instead of in  
Window? It sounds like you are proposing the following (Plan A):

A.1. Window contains ECMAScript-specific Timer API that can't  
possibly work for other languages and isn't very elegant even for  
ECMAScript.
A.2. Separate spec includes language-neutral and more elegant Timer  
API (with probably very few total interfaces, methods, and  
properties, but with probably significant interdependencies with  
Window, unless it leaves things majorly underspecified).

Is there any reason this would be better than (Plan B):

B. Window contains inelegant ECMAScript-specific Timer API for  
compatibility but also adds new elegant and language-neutral Timer API.


I like Plan B better for the following reasons:

- Window will specify a number of the interactions between timers,  
events and navigation in a fair amount of detail[1]. It's much easier  
to specify this for the new timer API as well if it is in the Window  
spec.
- It would be nice to specify how the two kinds of timers interact  
with each other[2]. Again this is easier if they are in the same spec.
- It doesn't make sense to have two different specs, both written by  
our WG, cover the same subject matter and provide different solutions.

The main disadvantages for Plan B would be:

- Ties Timer API to the rest of the stuff in Window
- Would result in Window spec having a little less purity in terms of  
not inventing features

My next major areas of work on Window will be fleshing out the  
Navigation section, cleaning up the Embedding section, and applying  
ISSUE resolutions to the spec. After that I will start on speccing  
out timers. So we have a bit of time to decide this. I'm happy to let  
someone else make the initial proposal of the new timer API, even if  
we included it in the Window spec.

Regards,
Maciej

[1] - For example, for interoperability purposes it is important to  
require that after you trigger a navigation by assigning  
window.location.href, no more timers will fire. Similarly it is  
important to require that timers don't fire while some other script  
is executing.

[2] - For instance, what kind of delivery order guarantees are  
provided between the two classes of timers? Ideally, if I set a timer  
for 10ms from now and then another for 20ms from now, then the first  
will fire first, regardless of what type of timer they are, and even  
if the implementation is busy doing processing for, say, 100ms that  
keeps it from firing timers.