Notices

Hi,
Imho the querying of apps, event reporting, and undertaking of actions is a must for a hacker device like the n900, and all applications should have the appropriate interfaces in place to support it. Actually I assumed something like this would be in place in maemo by default.
Some people said "isn't this a bit like option foo in program bar", but they are missing the point: something like this gives you total control to do whatever you want, depending on anything. configuration options are much more limiting, they cannot express the same level of flexibility.
Also, if you centralize the "brain" of the scheduling and event handling, you can make a lot of apps simpler, and better.

Personally I'm quite curious about the GUI approach. My first thought was that the semantics are too complicated to be expressed in a GUI (and hence, I would opt for letting users write in a script language)
However, if all plugins present their properties and events in a uniform manner, it may be possible to come up with a decent enough GUI that lets users easily write logic ("at this point in time, query this variable from program foo, if it equals bar, then wait this amount of time, then do this action, etc")

Btw, for scheduling, there is also the 'at' tool (atd) which may be a better choice then sleeping. although i'm not sure how exactly it's implemented.

I haven't read this entire thread yet, but I would just like to add that this Shepherd idea sounds fantastic! I can think of a few uses for it off the top of my head already and would definitely love to see this developed with a nice GUI

If you have ideas how to make a useful GUI feel free to add them here: http://wiki.maemo.org/Shepherd

I never saw a draft or something like this until now so I assume it's up to us (the community) to bring the ideas regarding the GUI together?

I have another idea about GUI. I didn't knew about shepherd before, so my girlfriend and I developed another application of this type. We started from the other side. You developed action and trigger framework and now think about language, that would tie them together. We have taken SWI-Prolog which gives very handy logic expressions and power of true complete programming language and added event-action framework and temporal logic operators. So we have simple tools for expressing things like "Do smth. if A started to happen and within last 30 minutes B was always true and existed such moment, that C was greater, than 50".

It occurred, that good documentation is needed to make people understand how to use it. Right now we have not much time because of graduation, but we try to improve it from time to time.

So, IMHO, GUI shouldn't express all that tool can give you. Look how many daemons with GUI there are for n900. It would be much easier to develop only GUI, which would write scripts for such language. There also could be GUI for constructing finite automates: create node, describe what conditions should have device in this node, connect nodes. If conditions are not met, switch to connected node, for which conditions are met. Describe what actions should be taken on transitions.
But I think, that GUI must be separate package from the daemon, which runs scripts. And I also think, that from theoretical point of view our approach with complete programming language (we called it ET-Prolog) and temporal logic has much better descriptive capabilities. But at current state it seems, that shepherd is more usable.

Not in maemo. Maemo has alarmd which is better than at or cron for one simple reason: it is hardware supported. It works when your phone is switched off. And it has powerful recurrence support.
Unfortunately there is only some doxygen documentation, several examples in the wiki, without recurrence support and that's all. We didn't manage to find any application, which uses it, but now you can see how it is implemented in ET-Prolog.

Alarmd does not support exclusions, but you can model them with boolean logic. I also use temporal logic for defining start and and of periods.

By the way. I couldn't find how to obtain shepherd and see how it is implemented. Am I right, that this topic and wiki page is everything available?

Alarmed is a GUI using alarmd to create recurring events and let the user define what should happen. I used it to rsync new pictures taken with the camera to a server on a daily base.

Yes, that's all as far as I know.

We're still in a bit of turmoil, as you know for the start of the thread, the 'original' shepherd was just a (slightly messy) bunch of scripts. A lot has changed since then - as you might have heard, I created a Qt-base core, and now that Shepherd will be a GSoC project there is a good change for rapid progress. I am now in the phase of moving the core to gitorious/extensively documenting so more people could join in and then we can really start kicking. The PR1.2 story threw a wrench in the works, but the good news is the availability Qt SDK and QtMobility, which I intent to take full advantage of (the ability to simulate the various HW sensors and their states really really helps a lot with testing plugins).

thanks attila77. did you see what KiberGus and I wrote on this page? not that i'm pretentious or whatever but I think these posts may contain interesting thoughts which may affect shepherd in a good way. KiberGus' SWI-Prolog-based approach sounds very interesting, as - what i also mentioned in my post - coming up with a language is though and should not be underestimated.

Any progress now since we got QT4.6 on the PR1.2?

Yep. QtMobility makes a lot of things a lot easier and ecksun, our GSoC "conscript" is already experimenting with availability plugins (it’s a shame every project could get only one slot, but hey, at least every project HAS GSoC help this way). I’ve moved (well, am still moving) the meat of the project to gitorious (expect stuff to appear here).

As for prolog, I see I forgot to comment on that: it’s a good idea and I very much like how one can define predicates for the logical expressions, but I would, at this point, still like to keep it simple, as in use only Qt components, especially for the core. While not technically cutting edge or radical, we do get JavaScript/JSON (and Python) and a state machine for free with Qt, and also a few parsers to go along with them. Don’t be afraid that most of these are not historically used in functional programming - we are still not doing polling - the plugins send async signals about their state/value changes so the core could reevaluate the trigger expressions. The effect we’re getting is in most cases something very similar to your proposal. My stance is, thus, at least until we do a proper release, to stick with the current components (considering my Pandora-style release schedule that’s the only way for people to actually see Shepherd ), and then we’ll see how much we could gain in perfomance/simplicity with alternative language solutions.