On Thu, Oct 2, 2008 at 6:20 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> On Oct 2, 2008, at 6:14 PM, Ojan Vafai wrote: > >> The thing is that often enough the place where you want to modify the >> delay you don't necessarily have access to the callback you would need in >> order to recreate the timer. So, you have to keep track of more stuff in >> JavaScript (e.g. a pointer to the callback). It's not the end of the world, >> but it makes for clunkier uses of the API. >> >> What do you think of the following? >> >> interface Timer { >> void stop(); >> void restart(double optional_argument_delayInSeconds); >> } >> > > Would restart change the time remaining as if that delay had been set > originally, or would it make the new delay the current time remaining? > Should it also let you change the repeating status of the timer? (That > doesn't seem hugely important but this way seems oddly non-orthogonal). > > Perhaps there should be a timeElapsed field (which would give seconds > actually elapsed since last fire, to the best precision the UA can manage), > which is useful for both recalculating delays and adjusting for jitter. > The way that makes the most sense to me is that restart would make the new delay the current time remaining. Having a timeElapsed field seems like a great addition that doesn't bloat the API. I really don't see any good use case for letting you change the repeating status, so I prefer leaving it out. > I think I will post it to a standards group soon, probably starting with > whatwg and possibly moving to webapps if Hixie thinks that is the right way > to go. We can discuss details further there. > Sounds good. This is great. It will make a lot of nasty code much cleaner. Ojan
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev