Re: Time in DOM 2 Events

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

And therein may be the real issue to consider.

While I honestly wouldn't complain if any base epoch were defined that
coincided with the one used in my primary environment (Java), I would
complain strongly if one were defined to have a different value.  And
likely when I used an environment with a different base epoch, I'd also
complain if its base epoch clashed there as well.

Since there's no clear need to define such a base epoch, and it's true
in general that time handling in a distributed system can be a tricky
issue of global system architecture, my original observation was that
it's not necessary to do more than say that the hosting environment (not
application, not OS, not DOM implementation) defines the base epoch.

Some environments can say more.  I'd support the Java binding saying that
the DOM epoch is consistent with the Java epoch (Jan 1 1970 midnight UTC).

- Dave

p.s. A couple minor comments are interspersed below; others may wish
	to skip them!
 


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

As I'd originally noted, transmission delays always need to be separately
accounted for.  Many researchers work on systems where interconnects are
fast enough that such delays can be ignored.  Not so on the web; the
round trip time to the other coast is perceptible in user interfacing
(at the user-stumbles-over-operation level, ouch!) even without much in
the way of network delays.

For me that's a real basic bit of distributed system design:  don't assume
you're on a fast LAN.


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

I'm still thinking you are indeed depending on much more synchronization
than you have admitted.  


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

Authoring -- sounds like you're talking about a distributed editor?

Perhaps you're doing some time synchronization implicitly, perhaps
through use of a transaction monitor that serializes concurrent
updates using some sort of appropriate protocol.  If that exposes
a DOM of some kind, then it'll of course be self-consistent ... but
it's essentially a single server API model, not a distributed system,
even if that transactional database is internally distributed (since
that internal synchronization wouldn't be externally visible).


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

Received on Tuesday, 8 February 2000 15:00:53 UTC