Re: FTPTeam: Programming fun task available

[Serafeim Zanikolas <sez@debian.org>]

[as always, cc me on replies]

On Sun, Oct 17, 2010 at 02:22:33PM +0200, Joerg Jaspert wrote [edited]:
> 2) each script has the information about itself, what it provides,
>    depends, priority. They are then linked into a directory, and
>    "dinstall" looks into that dir, and from all links figures out in
>    which order it runs them. (Hello init system once more :) )

Just to make sure I understand this:

- the dinstall /etc/init.d/ will have the sum of all scripts used by all FSMs
- each of /etc/rc{a,b,c,...} will indicates the nodes (scripts) of a FSM with
  links to the install /etc/init.d/
- the dinstall scripts will define priority/provides/requires (pretty much
  like lsb headers in init scripts)

I like this. It's more transparent and simple (and testing-friendly) compared
to a database.

In contrast to init however, I think of dinstall as a deamon that's waiting to
be fed an endless stream of work. Let's say that we use one text file to
describe every FSM instance (=job set).

We could feed job sets to dinstall by creating one tiny file per job set (with
fields like job set id, FSM type, archive, script args if any) in a directory,
say state/new/, for which dinstall registers for file creation events (via
inotify).

For extra transparency, dinstall could move these files from state/new to the
right directory to reflect the status of the associated job, eg.

state/new/
     /blocked/
     /ready/
     /running/
     /failed/
     /done/ (or simply removed alltogether when done)

If that's overkill, dinstall could populate these directories only upon the
receipt of a signal, as a way of checkpointing.

-S