<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 06/10/2015 03:02 PM, Stephen
Gallagher wrote:<br>
</div>
<blockquote cite="mid:1433948531.4274.29.camel@redhat.com"
type="cite">
<div class="moz-text-plain" wrap="true" graphical-quote="true"
style="font-family: -moz-fixed; font-size: 12px;"
lang="x-unicode">
<pre wrap="">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.</pre>
</div>
</blockquote>
<br>
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.<br>
<br>
Let's use this drupal related cron job as an example "<code
class="code">0 * * * * wget -O - -q -t 1
<a class="moz-txt-link-freetext" href="http://www.example.com/cron.php">http://www.example.com/cron.php</a>"</code> that many will be familiar
with which you would migrate to native systemd timers.<br>
<br>
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 ). <br>
<br>
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.<br>
<br>
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 ) <br>
<br>
JBG<br>
</body>
</html>