UX Engine: Timeline


Revision for “UX Engine: Timeline” created on 30 June 2016 @ 14:49:06 [Autosave]

UX Engine: Timeline
<h2>Functional Description</h2>The timeline service is responsible for the temporal orchestration of a DMApp (within a single household). Think: the director of an orchestra that reads the score and cues the individual musicians to play their parts. At service startup it needs to be given the parameters needed to contact the layout service for this DMApp, the parameters it needs to get the score document (or possibly the document itself) and some way to subscribe to the timeline synchronisation service for this DMApp.<h3>Verbs</h3><h4>createContext</h4>Sent by the layout service to indicate a new context has been created. The layout service needs to at least pass two parameters to indicate how the timeline service can access the layout service and the synchronisation service for this context, for example <i>layoutServiceUrl</i> and <i>syncServiceUrl</i>.<h4>loadDMApp</h4>Sent by the layout service to indicate a new Distributed Media Application is starting. A parameter (for example <i>timelineDocumentUrl</i>) needs to be passed to indicate the document describing the orchestration for this DMApp.<em>Issue: either the timeline starts playing straight away, or a second call <i>startTimeline</i> is needed. </em>It will now interpret the score (according to the current time updates provided to it by the sync service) and emit calls to the layout service to control starting and stopping of DMApp components (where media items such as specific images and such are considered a special case of a DMApp component).<h4>stopTimeline</h4>Informs the timeline service that this timeline has stopped playing. <em>Note: unclear whether this call is needed.</em><h4>timelineEvent</h4>Informs the timeline service that <i>eventIdentifier</i> has occurred, so it can adjust its timeline accordingly. The intention of this call is to allow alternate paths through the timeline (think: interactive quizzes, or secondary content on different levels such as beginner/intermediate/advanced that the user can switch between, or that the DMApp can switch between based on a users answers to previous quiz questions or something), and there must be a way for the DMApp to signal to the timeline service that such an alternative path has to be selected.Maybe this call needs a <em>globalTimeSpecification</em> if it can be scheduled for the future.<h4>clockChanged</h4>This is called to inform the timeline server of the current mapping between the per-context global clock and the wall clock. It has two parameters, <em>wallClock</em> (suggestion: let's use a floating point number specifying seconds since the Unix Epoch, in UTC) and <em>globalTimeSpecification</em>.<h4>Discussion</h4>It is not yet clear whether we also need <em>pause</em> and <em>resume</em> (but if we need the functionlaity maybe clockChanged can be used for that, by telling the timeline service that the clock speed is now zero). It is also not yet clear whether we need <em>seek</em> (and, again, these may be implementable using clockChanged).<h3>Verbs Needed from Components</h3><em>Note</em>: this section needs to go elsewhere (possibly both to layout service and app?) after editing. It is not about verbs <em>provided</em> by the timeline service, but about verbs <em>needed</em> by the timeline service. Either the verbs are provided by the components themselves, or they are provided by the layout service. In the first case, the components need to be addressable, in the second case the verbs need some <i>componentIdentifier</i> parameter.<h4>initComponent</h4>Initialize a component and assign parameters (media URL, etc) needed by a component.<em>Note: the need for the parameters is based on a model where the DMApp generally contains abstract components, such as "a video renderer", and the actual video to use is encoded in the timeline document. An alternative model is that the DMApp itself already contains all the needed information, but this limits reuse of the DMApp (think: translating it into a different language).</em>Even if the component already knows all its parameters beforehand an initialize call is still needed: the intention is that it allows a component to do preparation work before it becomes visible and/or active. Think of things like prefetching media items and such.<h4>startComponent</h4>Starts the component at a given time <i>globalTimeSpecification</i>, at media position <em>localTimeSpecification</em>. Ideally, this time will be in the future when the call is issued, so the timeline service can issue a couple of these calls to different components and know they will all start at exactly the same time. If the time given is already in the past the component should start as soon as possible.The <em>localTimeSpecification</em> specifies, for continuous media items, the position at which the media item should start playing back. This is needed so things like subtitles can be dynamically added and start playing back with the right synchronisation.<h4>stopComponent</h4>Stops the component at a given time <i>globalTimeSpecification</i>. See startComponent for timing issues.<h4>modifyComponent</h4>Modifies the internal (and possibly the external) state of a component at a given time <i>globalTimeSpecification</i>. Which bits of state can be modified remains to be seen (and probably depends on the component type), but one can think of media position, playback speed, etc. This call is needed so orchestrated changes (like a seek on the timeline, or jumping to alternative content) can be done in an orchestrated manner, under control of the timeline service.<h4>Discussion</h4>The order of the first three commands is always initComponent-startComponent-stopComponent. This set of verbs presumes that componentIdentifiers are like xml-ids and long lived. The initComponent parameters may not be needed for static DMApps, but will be needed when dynamically inserted content is used (for later use cases). The intention of including the globalTimeSpecification in the calls is that these calls can be issues prematurely, so the receivers have a chance to prepare (for instance by loading the media items). If a globalTimeSpecification specifies a time in the past the action should be executed as soon as possible.We may want to add an uninitComponent later, then the order of commands would be initComponent-startComponent-stopComponent-startComponent-stopComponent-...-uninitComponent. This would have the advantage that a component can be stopped but remain in their initialized state (with connections to media servers open, decoders allocated, etc) so that when things are dynamically hidden and shown again later there is less of a performance penalty. But whether we need this and whether it is useful depends on the API we select for migrating components in the layout service.<h2>API Specification</h2>To include specific data, communication substrate etc.Here is an example of an API definition - feel free to use similar formatting:<h3>dump</h3>The receiver of this message is expected to dump (part of) its internal state to its logging output, for debugging purposes.<ul> <li><strong>Publisher:</strong> debugging tools</li> <li><strong>Subscriber:</strong> all</li> </ul><strong>Example:</strong> <code class="json">{ "message" : "dump" , "what" : "random string that may influence what is dumped", }; </code>
Markdown content

OldNewDate CreatedAuthorActions
30 June 2016 @ 14:49:06 [Autosave]Jack Jansen
30 June 2016 @ 14:48:46Jack Jansen
28 June 2016 @ 12:22:57Jack Jansen
17 May 2016 @ 14:29:44Jack Jansen
19 April 2016 @ 15:18:21Jack Jansen
18 April 2016 @ 00:41:29Ian Kegel
Recent Posts
Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search