Re: [Jmri-developers] Fast Clock Design Questions

[Bob J. <Bob...@lb...>]

There are three parts to a clock, and I think they need to be kept 
separate in the software:

1) The timebase

In a real clock, this is the escapement & gears, the quartz crystal 
and counters, or something more complicated.  In a software clock, 
this is the piece that can answer the question "What time is it now?" 
It needs to have methods for setting a rate and an initial time, but 
that's about it.

The simplest possible timebase just provides the current system clock 
as it's result; this only provides a "X1" speed and no separate time 
(e.g. when the computer says 10AM, it's 10AM)

A more complicated one would listen to a LocoNet, and convert that 
time signal into an internal timebase (it's complicated because it's 
only updated at intervals, so you have to free-run in between; see 
Alex's comment)

The most common one would use the internal clock and some 
calculations to make a fast clock with separate rate and offset.

2) The display

This puts the current time somewhere useful, and since there are lots 
of "useful" things, it will need to have lots of forms.  One might 
send it out across a LocoNet or other network to notify people; 
another might display it on the screen,  yet another might announce 
it via a voice.  These should be completely independent of the 
timebase, so that you can pick and choose your combination of 
timebase and display.  A display might be able to also display the 
fast rate, etc, and in that case would also get those from the 
timebase.  It will have a few setable parameters:  How often to 
update is the only one I can think of right now.

The simplest one of these is just a Swing window with a one-second 
timer that updates a text field containing the current time.

3) Alarms

"Do this at the following time" is separate from both a timebase and 
a display; so is the management of multiple requests of that type.




Would it be helpful for me to provide some Java interfaces for these 
to show my thoughts?

I can easily imagine a user with a display & timebase but no alarms; 
with alarms and timebase but to display; and even with a timebase, 
but no alarms or display.  So they should be kept as separate sets of 
interfaces & classes in the code.

Bob

-- 
--------------
Bob...@lb..., +1-510-486-7355, fax +1-510-643-8497, AIM JacobsenRG