RE: [Widex] suggestions re timestamps

[<[e-mail]>]

Dave,

I agree with your proposal to define the timestamp as "non-negative
integer denoting the number of milliseconds from the current reference
point". This can be considered as good baseline for processing time
stamps which probably suits most environments.

Looking at how REX is defining the meaning of the timestamp (e.g. "an
integer in milliseconds relative to the epoch") I noticed that the
format is the same (e.g. an integer) and only the processing model is
different. The difference between the Widex proposal and the REX model
is that Widex has relative reference point while REX has absolute
reference point (e.g. 00:00:00 UTC 1st January 1970).

There are good reasons for using relative and absolute reference points
depending on the deploying environment. In order to better accommodate
these environments, the Widex framework can make use of the Service
Discovey component to enable the Widex Renderer and the Widex Server to
negociate and agree on a common processing model for the timestamp.
Thus, we can consider that the relative reference point is the default
processing model for timestamps but more demanding environments (e.g.
MORE - where streaming is involved) can use the absolute reference point
as defined by REX.

In addition, by negociating the processing model for the timestamp
during service discovery step, we allow particular environments to
deploy their own processing models, which could be undefined at this
time, without affecting the core Widex framework.

Vlad

>-----Original Message-----
>From: ext Dave Raggett [mailto:[e-mail]] 
>Sent: 24 March, 2006 19:15
>To: [e-mail]
>Subject: [Widex] suggestions re timestamps
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>In the face to face meeting on Thursday, we discussed the 
>potential problems with how REX specifies timestamps for 
>updates that are intended to be applied at a future time.
>
>REX currently specifies these in terms of the renderer's clock 
>as milliseconds since the start of 1970 GMT. The problem is 
>the likelihood of a significant clock skew between the 
>renderer and the server, and the latency incurred by the 
>protocol. This makes it difficult to the server to set the 
>appropriate timestamps when the update is to be applied in a 
>relatively short time interval into the future.
>
>In principle, the server may be able to estimate the clock 
>skew and the network latency from a sequence of interactions 
>with the renderer, but this is tricky and subject to uncertainties.
>
>W3C's SMIL language deals with this by allowing you to specify 
>event timestamps in terms off timed offsets from other events 
>(the beginning or end of a give presentation). SMIL isn't 
>itself a solution to Widex as it doesn't deal with the means 
>to transport DOM events and updates.
>
>Widex/REX could use the SMIL event-value syntax, which 
>includes a reference to a named event and a signed time 
>offset. This would be very general, but comes with an 
>implementation overhead that may not be acceptable in all 
>environments. A simpler approach would be use non-negative 
>timed offsets from an implicit reference event. You would be 
>able to designate that a given event is the new reference 
>point, replacing the previous reference point. The initial 
>reference point is the start of the session.
>
>This technique avoids the need to record the times of events 
>as they are applied. You only need to record the time of the 
>current reference point. The syntax for identifying an event 
>as a reference point would involve a new attribute. The 
>existing timestamp would be refined as a non-negative integer 
>denoting the number of milliseconds from the current reference point.
>
>For multimedia presentations, the audio track is often used as 
>the reference timebase since human perception finds disruption 
>to the audio more disturbing than to the visual presentation.
>A question for the W3C REX task force is whether they are 
>interested in synchronizing SVG updates to streaming audio, 
>and if so whether the presentation can be paused/resumed. If 
>yes, then this should be taken into account in the semantics 
>for timestamps, e.g. the clock should be paused along with the 
>presentation.
>
>Comments?
>
>
>  Dave Raggett <[e-mail]>  W3C lead for multimodal interaction
>  http://www.w3.org/People/Raggett [phone] (or 867351)
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>
>iD8DBQFEJCkFb3AdEmxAsUsRAmG1AKCiQWEkIYxLYmAOhQIYlxmhnByyEgCgn3bl
>+M+Bs9+lJX/0L5mtiu2xYvM=
>=UZF3
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>Widex mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/widex
>

_______________________________________________
Widex mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/widex