[systemd-devel] Creating units using D-Bus

["Jóhann B. Guðmundsson"]

On 06/10/2015 03:02 PM, Stephen Gallagher wrote:
> You make some good points Jóhann. It probably does make sense to focus
> (at least at first) on managing timer units shipped alongside services
> as opposed to trying to develop a UI for managing arbitrary timer
> units. I'll discuss this with some of my colleagues.
>
> That said, there still may be some value in enabling the creation of
> new timer units for these purposes. (For example, there may be timers
> that are only useful if two normally-unrelated services are installed,
> so neither one would be likely to ship such a timer in their package,
> even disabled). But it's hard to say whether that's worth designing for
> or solving by shipping additional packages with helper units.

Now that I see that you have started to understand what I tried to 
convey when running that cron to timer migration but failed miserably in 
doings so, going to say that value is an illusion Ithrow in another ( 
real life ) example to complex matters further.

Let's use this drupal related cron job as an example "|0 * * * * wget -O 
- -q -t 1 http://www.example.com/cron.php"| that many will be familiar 
with which you would migrate to native systemd timers.

Shipping this with drupal cannot be done since you cannot bind that to a 
specific web server ( the installed server might be apache, might be 
lighthttp or might be nginx etc ) not binding it to the web server will 
keep this timer unit running with all it downside once the administrator 
shuts down the webserver ( as happens currently with cron ).

What I'm trying to emphasize here there exist only one to one mapping 
with each service ( or target )  and timer unit and those two things 
need to be bound together.

With my former cron to timer feature and serverWG hat on, what I would 
propose and do which is quite the opposite from what you propose here  
is have all components ship their cron job in a separated sub-package ( 
those are mostly crap anyway ) then design the cockpit UI in such manner 
that dissociates cron job and uses generic term like for example 
"scheduled task" which covers both solution and whatever the future 
might bring and offers the user to create an arbitrary task ( which 
would use cron and have screen(s) tailored to that and create and 
associate task to an service ( with screen(s) tailored to that which 
would use timers )

JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150610/c9dd301d/attachment-0001.html>