Werner Almesberger <[EMAIL PROTECTED]> writes: > So I think what we should have is just a general state machine. > That's flexible, easy to understand while it's simple, but still > manageable when (not if ;-) it gets larger and more complex. > > It's also straightforward to translate layered state machines into > a single one, if that need should ever arise. > > Another issue is the configuration language. When I have to solve > a non-trivial problem, I usually ask myself "in what language could > I express this elegantly ?". The answer to this shouldn't be "C", > "Python", or such, but rather a new language - designed for the task. > > If I notice that this new language really just does what an exiting > one does well already, I just pick that one. But if the difference in > degree of abstraction is large enough, I then make this new language > the centerpiece of the design, and work up and down from there. > > I also tend to make sure that my languages are valid CPP input. That > way, I can make things optional and work with macros, keeping my own > language compact while still having powerful instruments to fight > redundancy. Redundancy is, of course, my number one enemy, even > before complexity. (*)
Smells like Lisp to me ;-) The Daemon Managing Daemon[1] sort of does this. Alas, like all things Hurd related, it looks very unmaintained and potentially (a cursory test shows that it at least starts with 1.8 and git head) broken against the latest Guile. And it is Guile so I suspect almost everyone would hate it with an undying passion. In DMD you define various runstates and services and have full control over what is running via arbitrary combinations. You just drop a command into its command socket (each service type can have an arbitrary set of commands and services are defined via GOOPS classes so you can do inheritance of commands) and it reconfigures the system. New commands and system states can be defined in Scheme fairly easily, and, being Scheme, it is more or less infinitely existensible. It also uses a sane dependency system allowing it to start independent components of the dependency graph in parallel (it's been a while since I used DMD and so I forget whether it implements this yet). The really killer feature of course is the existensiblity via GOOPS classes. Need a new 'runlevel' for airplane mode? Ok just define an <airplane-mode> class and have it invoke services to shutdown GSM but leave the rest of the system running; rather than having separate daemons to initialize the system, to figure out what to stop on suspend, to decide what device states need to be restored on resume, to reconfigure the system for various states (e.g. airplane mode), etc. there could be a single daemon managing all of them. All with the flexibility of the Scheme (and old style `defmacro') macro system for defining new DSLs for each of these subtasks (or potentially the guile-library LALR module if non-sexp syntax is desired). Why have a dozen daemons for a dozen somewhat similar tasks when you could have one very flexible daemon for all of them? Farewell Redundancy *and* Complexity and Hackish 1970s Init. [1] http://directory.fsf.org/project/DMD/ -- Jessie: i thought your beard took the oxygen from the air and made it breathable for you
