- From: Francois Daoust <fd@w3.org>
- Date: Fri, 10 Jul 2015 18:38:26 +0200
- To: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
- CC: public-webtiming@w3.org
On 2015-07-09 12:03, Ingar Mæhlum Arntzen wrote: > Hi Francois and CG members. > > > Thank you Francois for your excellent work and recent proposal. We very > much share your opinion that CG specifications must detail how the > timing object > > 1. > > connects to online timing objects > > 2. > > connects to media elements I submitted two pull requests for these first two points. TimingProvider interface: https://github.com/webtiming/timingobject/pull/7 First stab at associating a media element with a timing object: https://github.com/webtiming/timingobject/pull/8 I had to shuffle things around and to revisit terms and interfaces defined in the spec to be able to introduce a proper TimingProvider interface. I kept that interface minimal, on purpose. Since the user agent will not be in a position to control the quality of the code produced by a timing resource provider, it cannot "trust" it so reducing the number of things that a timing resource provider could do wrong is important, especially considering that regular Web app developers may act as timing resource providers in practice. Typically, I dropped the "query" method on that interface in favor of a "now" method that simply exposes the clock used by the provider. The goal was not to end up in a situation where the provider fails to report a change on the current state vector and still uses that information to compute new state vectors, leading to chaotic moves. Similarly, I stuck to a simple "one error closes the timing object" mechanism for errors. Essentially, if something goes wrong, the timing object switches to a "closed" state where it cannot be used anymore. That is consistent with the way WebSockets are defined for instance. I listed a few open issues inline but I'm confident that most of the things I wrote will need to be fixed or improved, and that interfaces and procedures will have to be modified in particular. I still hope this goes in the right direction :) Thanks, Francois.
Received on Friday, 10 July 2015 16:38:40 UTC