Re: Multi-device Timing Community Group

HI Anssi

Adding to what Francois says here, multi-device timing (based on shared
motion) is very useful in implementing some of the use cases that also
motivate the webscreens initiative. For instance, take the use case where
you want to control a web-based slide show presentation on a big screen
from a smart phone. We solve that by letting shared motion (online)
represent the "position" in the slide show, and then we just increment
(move) the position (on the server) in order to navigate the slide show.
The big screen needs a URL to the slide slide show and the smart phone has
a URL to the controls web pages and possibly also including the slide show
viewer. This server-based approach has additional benefits, for example,
any number of devices could join the multi-device slide show presentation,
or (if you wish) the slide show can be controlled by one, everyone, or
perpaps a group of presenters, or even a presenter that missed a flight
connection and is stuck in an airport.

So, we see multi-device timing as an enabler for the construction of Web
media that is naturally multi-device, thus reducing the secondary screen
problem to a bootstrapping problem of possibly detecting other devices and
somehow get a URL across. (This is out of scope for multi-device timing -
but within scope of the webscreen group I believe).

With respect to simple screen casting of web pages, we could also represent
that by having a "playlist" of urls on a server, and simply navigate that
using shared motion, letting each connected device render the correct page
at the same time. If you additionally let that server-hosted playlist
accept dynamic updates, that is a fairly powerful mechansim for
collaborative viewing of Web stuff.

Hope this helps sorting out the relevance :)

Best, Ingar













2015-03-18 9:33 GMT+01:00 Francois Daoust <fd@w3.org>:

> Hi Anssi,
>
> On 2015-03-17 11:22, Kostiainen, Anssi wrote:
> [...]
>
>> I observed there's now a Timing Object draft spec that "aims to make it
>> possible and easy to synchronize playback of media (and non-media) content
>> across Web clients":
>>
>>    http://webtiming.github.io/timingobject/
>>
>> The spec attempts to address the use cases are described at:
>>
>>    https://lists.w3.org/Archives/Public/public-web-and-tv/
>> 2014Dec/0017.html
>>
>> Francois - since you're the editor of the Timing Object spec, you're
>> probably in the best position to give us an update on how this might fit in
>> with the potential future extensions to the Presentation API that this
>> Community Group may be working on.
>>
>
> Ah, we were trying to hide the spec until Ingar fixes some of the nonsense
> I wrote in there. I guess we failed ;)
>
> The Timing Object spec is a rough first draft attempt at defining timing
> resources on the Web while trying to align with existing HTML5 concepts. I
> don't expect the spec to be anywhere near stable at this stage. The main
> goal is to have something concrete to chew on to bootstrap discussions
> within the Multi-Device Timing Community Group. Actually, the spec has not
> yet been shared with the Community Group but will soon be.
>
> Within the Multi-Device Timing Community Group, the idea is to follow a
> classic client-server architecture where synchronization between device A
> and device B is achieved by synchronizing each of them with an online
> timing resource hosted by some timing server S.
>
> I do not know yet how this could fit in with potential future extensions
> to the Presentation API. There may not be any need for it to fit in,
> actually. Or the need may arise if the proposal gets extended to cover
> synchronization using peer-to-peer communication channels.
>
>
>  My expectation is the work on Timing Object is too early to be of
>> relevance to the Presentation API spec being worked on in the Working Group?
>>
>
> That's correct!
>
> Francois.
>