Re: SVG12: Timer and createTimer()

Dear Bjoern,
This is the response to your Last Call Comment from email
(http://lists.w3.org/Archives/Public/www-svg/2006Mar/0129.html), which
is copied at the bottom.

Your questions have be repeated here one at a time so the answers
may be presented more easily. These answers reflect the specification
changes which the WG has made to address your comments and the comments
of others. Thanks for your feedback, please let us know shortly if you are  
unsatisfied with these answers.


Bjoern asks: What state is the Timer in directly after creating it?
Is it running or waiting, and what are the values of .delay and .interval?
(These seem to be uninitialized in which case I would not
know how the Timer should behave when started.)

Reply: The initial state of a Timer is waiting.  The initial values 
for delay and interval (now called repeatInterval) are provided in the 
createTimer method. This method raises an GlobalException DENIED_ERR if the 
values are not given.


Bjoern asks: What is the behavior of stopping the timer between starting it
and dispatching the initial timer event? Would this prevent dispatching the
timer event? 

Reply: Yes, calling the stop() method puts the Timer into a waiting 
state, but does not change the values of delay and interval, nor does it 
cause the SVGTimer event to fire. The event is triggered only when the 
interval is run to completion.


Bjoern asserts: (It seems that yes, that would prevent it, so .running needs
to be checked before dispatching the event. This is however not clear
from the draft.)

Reply: We believe the updates make this very clear.


Bjoern asserts: It is not clear to me when .delay is significant when the 
timer got re-started.

Reply: The delay is updated dynamically to reflect the time remaining until
the next event is triggered. If the timer is stopped before the interval is
completed then the delay will have a positive value. As noted above the 
delay value will not be reset. When restarted the timer will run the for the 
remaining delay and then trigger an SVGTimer event.
    

Bjoern asserts:  It seems to me the delay should be from the start of the timer,
not from some undefined "first execution".

Reply: As you suggest the delay is time from the start of the timer until the 
event is triggered. Not time since last event. That was always the intention,
and the spec now more clearly states it as such.


Bjoern asserts: I note that the word "execution" does not fit well into this 
model, the Timer just generates events at specific points in time, which would 
then cause event listeners to get triggered.

Reply: Agreed. The phrase containing "execution" is replaced with a reference 
to the event. For example in the description of delay it reads: 
"This attribute specifies the time remaining in milliseconds until the next event is fired."


Bjoern asserts: The event flow inside the Timer is not clear to me, it seems 
events only ever accomplish the target phase, but the draft does not say.

Reply: The new text description for SVGTimer specifies that this is target phase 
only and on the Timer object itself. This is reiterated in the Timer interface 
description.

	
Bjoern asks: When are timer events dispatched if .delay or .interval are modified 
after the timer has been started?  

Reply: Updating the interval (now called repeatInterval) will cause the next 
interval to be of the new interval duration. Updating the delay will change the 
current remaining delay to the new value.

Bjoern asks: How do stopping and restarting the timer affects this?

Reply: Stopping the timer stops the count down and thus the update of the delay, 
i.e. it pauses the timer. The values for delay and interval are not modified by the stop 
and start methods, so resuming the timer by calling start() will resume the count down 
from the point where it was stopped. Updating the interval (now called repeatInterval)
will cause the next interval to be of the new interval duration. Updating the delay 
will cause the current interval to be changed.


Bjoern asks: What the effect does calling start on an already started timer have?

Reply: None. This is specified in the new description text for the start method.


Regards,
Andy Sledd on behalf of the SVG WG


------------------
From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 17 Mar 2006 13:55:47 +0100
To: www-svg@w3.org
Message-ID: <7gbl1255spq2lff839rgvtve56l37tn2du@hive.bjoern.hoehrmann.de>  
 
Dear Scalable Vector Graphics Working Group,

  http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/svgudom.html defines
the Timer interface and the associated createTimer() method. I tried to
implement these, but failed due to the following issues. Please change
the draft such that the following is well-defined.

It is not clear what state the Timer is in directly after creating it,
e.g., whether it is running or waiting, and what .delay and .interval
are set to. These seem to be uninitialized in which case I would not
know how the Timer should behave when started.

It is not clear to me whether stopping the timer between starting it
and dispatching the initial timer event would prevent dispatching the
timer event. It seems that yes, that would prevent it, so .running needs
to be checked before dispatching the event. This is however not clear
from the draft.

It is not clear to me when .delay is significant when the timer got re-
started. It seems to me the delay should be from the start of the timer,
not from some undefined "first execution".

I note that the word "execution" does not fit well into this model, the
Timer just generates events at specific points in time, which would then
cause event listeners to get triggered.

The event flow inside the Timer is not clear to me, it seems events only
ever accomplish the target phase, but the draft does not say.

It is not clear to me how implementations determine when to dispatch the
timer event time if .delay or .interval are modified after the timer has
been started, of how stopping and restarting the timer affects this.

Finally, assuming that .start() might have any signifance relative to
the issues above, it is not clear to me what the effect of calling start
on an already started timer is.

regards,
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de <http://bjoern.hoehrmann.de/>  <http://bjoern.hoehrmann.de/> 
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de <http://www.bjoernsworld.de/>  <http://www.bjoernsworld.de/> 
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ <http://www.websitedev.de/>

Received on Wednesday, 19 July 2006 21:38:30 UTC