[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pyatcron-devel-list] Explanation on the cron time entries (Was: Som
From: |
Julien Olivier |
Subject: |
Re: [Pyatcron-devel-list] Explanation on the cron time entries (Was: Some comments on Brian code) |
Date: |
Wed, 19 Nov 2003 11:27:13 +0000 |
On Wed, 2003-11-19 at 08:01, NICOLOVICI Xavier wrote:
> Hi everyone,
>
> I love those long thread discussions on specific topics, this is why I love
> open source coding, it makes people think by themselves.
>
> Okay, here is my two cents tip about this */45 cron entry.
>
> According to the Cron documentation, the "/X" is the step that cron should
> use to browse the prepending unit range. In other words, "4-10/2" means start
> from 4 and step forward 2 digits until you reach 10. So, the "*/45" entry
> should execute the task every 45 minutes (according that hour entry is "*" of
> course).
>
> So we might have a problem using arrays of integer to expressed that, but
> lucky we are, Python doesn't really matter about the type of variables. The
> function prototype should expect a list (or array if you prefer), but in
> Python, a list can contain every kind of type, even a mix of different types.
> According to that, the setMinute() function prototype (and the others for
> hour, date and so) should be setMinutes(<list>) and the getMinute() function
> should return a string with the <list> values comma separated. What do you
> think of that, does it sounds good?
> On top of that, this comma separated string should be returned by the
> CronEntry class getCommand only. The AtEntry one won't have to deal with
> interval, as At is a "one shot" execution.
>
Why not simply using strings everywhere ? In fact, we will do nothing
with these parameters except write them to the crontab file. So I think
a string is more than enough, don't you ?
> Now, the problem I see will be more on the GUI side. We will have to think
> about a way to let the user plan such tasks (every XX minutes, or every YY
> hours). For me, the real problem is here. How the GUI will be designed to
> allow such entries?
>
Well, we could have something like:
----
Execute the task on [ ]/[ ]/[ ]
[ ] Then, repeat the task every [XXX ] |Seconds |
|Minutes |
|Hours |
|Days |
|Months |
|Years |
----
Wouldn't that cover most of the cases ? Of course, we could use Brian's
advanced schedule dialog to tweak it up later.
--
Julien Olivier <address@hidden>