Re: [Clockwork-developers] Implementation of a decentralized schedule

[Joel L. <jo...@lo...>]

+- On Monday (1/14/2002 10:40) Charles Brian Hill <br...@do...> Wrote-
| When you have some time, let's (all) continue to bring up the pros and
| cons of both approaches.  The best way for us to determine a course of
| action is to fully understand the problems we might encounter when we
| implement them.  The more we understand the question, the better the
| answer we'll give.

It's been several weeks since we talked about this, but I hope it's not
too late for me to put in my two cents. Here's what I see as the advantages
of both the centralized and decentralized schedule:

CENTRALIZED:
------------

good:
* Management software is simpler because the entire schedule is in one place.
* We already understand a half-decent model for this type of system.

bad:
* At least one system has to run the scheduler. Probably more than one if
  you don't want a single point of failure. In a large schedule, these would
  need to be dedicated systems, adding to the overhead of the scheduler.


DECENTRALIZED:
--------------

good:
* Low/no overhead: you can run a schedule without dedicating any systems
  to be "the scheduler."

bad:
* Updates to the schedule would have to propagate to individual nodes.
* The management GUI would have to poll (or subscribe to) lots of systems
  to get an idea of the current state of the schedule, which would probably
  result in a delay between starting the GUI and looking at current data.
* Multicast IP: I don't know anything about it, and some users might not
  be wild about being forced to use it.
* We don't have a well-understood model for this type of schedule, so we
  won't be able to learn from someone else's mistakes.


If you see something I missed, please reply. I hope Brian's offer to
consolidate and post the list is still good.

-- 
Joel