RE: Time in DOM 2 Events

> 
> > > > For most applications, local start of epoch is fine.
> > > > Nevertheless, for distributed apps (e.g. coordinated 
> > > > display of document sets; events that
> > > > will be delivered in a media stream with delivery
> > > > timestamps), a common epoch would really help.
> > >
> > > Not unless there's also elimination of clock skew, which 
> would mean
> > > also depending on some additional protocol like NTP.
> > 
> > This is orthogonal - I am just looking for a value in the 
> same nominal
> > range.
> 
> It's part of the same problem.  You'd described a model that assumes
> distributed clock synch; you can slice it into smaller parts 
> than that,
> but you can't get away from needing solutions to all of those parts.
> 
> In the kind of systems design environments I've worked, designs
> requiring much in the way of clock synch have been explicitly avoided:
> they usually create more problems than they solve.

Agreed. I have also worked on real time sync or multiple devices etc. and
know what you are referring to.  I see why you would think I am headed in
that direction, when in fact all I want is a consistent definition.  I
understand that it probably is not useful in many cases to use something
other than the system-defined epoch. Since people will convert times
relative to one another, or the start of a presentation, it does not in
general matter anyway.

> 
> As a rule, protocols using time deltas have fewer systematic failure
> modes.  They don't depend on the origin of the clock range, or the

If you transmit them, they break down just as quickly. In addition, since
other events are often scheduled relative to a local perception of calendar
time, the deltas can cause more problems that absolute times.  I believe
your use-cases, but I have seen both sides of this.

> correct setting for any given system's clock.  (I've had occasion to
> look at such settings on various networks -- by the time you even get
> to a hundred systems, it's hopeless.  Even rocket scientists get time
> zones and DST settings wrong, regularly.)  And small origin deltas are
> less likely to suffer from errors caused by differing clock rates, or
> from the variable latencies inherent in network transmissions (which
> need to be separately evaluated and accounted for, in any case).

This all assumes you are trying to achieve network sync, which I am not.  I
want to describe a time and use a coordinated epoch.  I can always use
another format, if need be (and may well do so anyway in many cases).

> 
> 
> > > But I was unaware that anyone was really proposing that 
> DOM would be
> > > the wire protocol in such a case.  I never understood that to be a
> > > design goal, and never heard protocol considerations 
> (like minimizing
> > > round trips) raised.  The natural way to use DOM in such 
> distributed
> > > apps would be as an API used to mediate access to some 
> other protocol,
> > > which supported caching, synchronized updates, and so on. 
>  That lower
> > > protocol layer would address whatever level of clock synch is
> > > necessary,
> > > and perhaps add a constant to use the appropriate epoch.
> > 
> > I did not mean that DOM would do any of this, just that we 
> have a consistent
> > epoch definition. For my applications, the timestamp is 
> used for scheduling,
> > and can be predelivered (eliminating issues of skew, etc.). 
> It simplifies
> > things if everyone is talking the same nominal range.
> 
> Patrick, you can't have it both ways.  Either you're talking about
> a single system, in which case there's no issue, or you're talking
> about multiple systems, in which case your premise is that there's
> distributed clock synch.

We are talking at cross-purposes. I do not disagree with your contention,
but am talking about a different issue. I am talking about a single
performance system, but authoring for distribution on various systems. 

If we have to go with system-defined epoch, it will not break my heart.

Patrick

Received on Monday, 7 February 2000 21:52:20 UTC