On Tue, 05.02.13 11:54, David Strauss (da...@davidstrauss.net) wrote: > > Repeating myself, but I'll say it again: I strongly prefer a feature > set that is a subset of iCal/xCal [1]. I'd like it to be possible in > the future to expose existing and future runs via CalDAV over > something like the gateway. > > iCal already supports "last day of month schedules": > > FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=-1 > > Maybe we should make it more systemd-ish in how we specify everything, > but it's all there. Developers have given the administrative > requirements of recurring events decades of thought and mostly arrived > at iCal, and Apple, Google, and other calendar implementers have > standardized on it. There are also FOSS libraries for computing > recurrence times in the iCal format [2]. libical has friendly > licensing, uses GNU Autotools, returns cleanly on memory allocation > errors, is actively maintained (frequent commits), is broadly used in > production services, includes pkg-config data for easy linking, and > comes packaged in major distributions like Fedora.
We are very conservative in adding new deps to PID 1. PID 1 is an almost kernel-like environment, if it goes down the entire system is lost. Pulling in another library into this, that so far has not been part of the usual Linux stack, for a relatively peripheral use is not really something we are particularly keen on. And we cannot really make this an optional dependenciy either, since that might have the result that people can write timer files that parse on some systems but not on others, and we really want to avoid that. Ultimately, if we really would want such a complex recurrence logic in there, then it would probably be easier to just reimplement it. It's not that hard really, the syntax does not appear particularly complex to me, looking at http://www.kanzaki.com/docs/ical/recur.html ... That said, I am not even convinced we actually do want the complex recurrence logic of ical here. Currently, the language implemented may be used to declare repetitive events where the engine will always calculate the next occurence right after a the job finished running the last time, and then trigger the event on that. As next step, whe then want to add anacron-like functionality where this logic learns persistance, and thus the last execution time is saved to disk so that we can take this into account after a reboot, too. However, the ical recur stuff goes an important step further beyond the current logic: COUNT= may be used to indicate the total amount of executions, but that's something very different from what is implemented now. The currently implemented scheme does not specify anything about the number of times something is executed, it leaves that pretty much open, it just declares that when -- after a job is completed -- the next time should be scheduled. If a job however runs very long (so that it overruns the next occurence), the current implemenation (and syntax) will not retrigger immediate reexecution. Now, adopting the ical syntax hence would also mean that to be fully in compliance with its logic we would have to improve the engine to count previous executions and possible persist that to disk. Of course, one could claim that this is a tiny detail we could just ignore, but I believe picking a good calendar language is mostly about getting these details right. I mean, it took us a long time to finally add calendar scheduling support to systemd. The reason for that was not that this was inherently a hard problem (it's not hard really, it took me a day or so to implement in the end), but it was that we were so unsure about the calendar expression language we should use for this. David, you had proposed ical a while back already, and we looked into that in detail. We however were a bit uncomfortable with the syntax, as we figured the ISO date notation was not really that nice to type for humans, and due to its heavy use of upper-case for the recurrence stuff, abbreviations and other syntax pecularities it kinda felt a bit alien in the rest of the systemd syntax. We looked into various other syntaxes we found, and temporarily even considered just taking over the old cron-syntax, because that was very simple at least. We also felt that supporting redundant calendaring languages would be a big mistake, we should stick to one, and make it a good one, rather than supporting multiple ones with all each individual shortcomings. The syntax we finally settled on is mostly inspired (but different in some key areas) by Uwe Ohse's work on uschedule: http://ohse.de/uwe/uschedule/uschedule.html When I found that I was really happy, because these time specifications where easy to write, easy to read, and still substantially more powerful than cron. This language was particularly nice as normal timestamps were naturally extended to recurring events. Timestamps hence mostly became a subset of repetive event specifications, and what we output is very close to what we pars.e And so we took that, adapted it a little and used that in systemd. Now, I can totally see the benefit of being able to map iCal events to timer units. There's a strong usecase behind that, I can totally see that. However, I wonder if it wouldn't be better to actually treat that as that what it is, i.e. a "mapping" problem. So maybe the approach here could be to figure out in detail what ical can express right now, that systemd cannot right now, then maybe update systemd to do a little bit more, and then document in the wiki how we propose the mapping to work if clients want to do that, including example code. And all that while documenting explicitly where the ical logic differs from the systemd logic, like for example for the COUNT= part pointed above. (I have now added this to the TODO list.) Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel