Re: Time in DOM 2 Events

Hi Patrick,

> > > 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.

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
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).


> > 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.

There are better design alternatives for the latter situation, ones
which don't impose so heavily on the rest of the network operations
framework.

- Dave

Received on Monday, 7 February 2000 14:20:59 UTC