Scheduling subsystems (crontab, at) and the desktop

[Maciej Katafiasz]

W liście z czw, 22-07-2004, godz. 14:55, Maciej Katafiasz pisze: 
> Just to let you know, we're working on modern replacement for cron, but
> with much wider scope that just scheduling and fully DBUS based
[snip]
> I'm going to prepare much more detailed writeup in next few hours or so,
> so stay tuned :).

As promised, here is a tad longer description of Eventuality framework.
If I'm not clear enough, please ask, I'll gladly provide you with
answers, but I hope that together with what was already said in this
thread, you'll get good overview of the idea.

Eventuality is framework designed for, amongst other things, replacing
legacy cron jobs as means of performing prescheduled actions. This is
however only small part of what is the intended functionality for
Eventuality.
Basically, framework is functionally split up into three parts:
- one that lets "producer" apps register actions they support. For
example, movie player can have "PlayMovie()" action, with parameters
like "URL" (string), "Fullscreen" (boolean) and "Volume" (float).
Interested apps can later query for supported apps, and use them in
their own events
- second one that lets "consumer" apps use defined actions to define
events. These events can be potentially quite complex, and consist of
several actions. Once made, event is fed into framework and then
consumer app can forget about it, relying on framework to take care of
executing it when appropriate conditions are met
- finally, there's glue part that ties everything together and provides
facilities for registering and keeping track of actions and
consumer-defined events (hereafter called "events"), and providing
outside events (hereafter called "triggers") notification
So, you can see Eventuality as a kind of "application automation meets
cronjob" type of thing. However, there are several more things to it
that make it interesting, in no particular order:
- it will use DBUS for everything. Whenever there's a reasonable way to
solve some of issues by using DBUS, we will prefer it over any ad-hoc
hack
- although desktop oriented, Eventuality is meant to be sysadmin's tool
as well. That's why we'll struggle hard to not to require any
GUI-specific hacks, nor other things that would make it unwieldy for
sysadmin
- there's possibility to use flexible choice of trigger types. Ie, time
flow related triggers source is the most obvious case, but not the only
one. It is equally feasible to make "button press" the trigger, and make
panel launchers for arbitrary event
- event dispatch will be handled in a way that's cross between signal
handling a'la GUI toolkits (handlers are invoked sequentially, until
there are no more of them, or one of handlers declares it fully handled,
stopping further emission) and exception handling in programming
languages (handlers are matched from most specific to least specific
one). This way, one can create events with nonlinear execution path,
like "if user is active, display notification on-screen, if not, send
SMS to her cell#"

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl