[Pyatcron-devel-list] Cron file definition

[NICOLOVICI Xavier]

Hi there,

Reading Julien's remarks, I've found that he suggests to insert comments in
crontab to identify pyatcron tasks. Why do we need comments? Defining a
strong naming scheme will do the trick. Some explanation.

Think about the foolwing crontab file:

* * * * * pyatcron-ftp-download ftp://somewhere.org/somefile.txt
/my/home/dir/.
* * * * * logrotate
* * * * * pyatcron-archiver /dev/fd0 /folder/to/backup

Do you think that we need any comments to identify pyatcron task and their
parameters from normal tasks?

Can we say that pyatcron tasks MUST be script starting with the "pyatcron-"
string? More on that, we could imagine that pyatcron tasks start with
"pyatcron-" and are run from /usr/share/pyatcron/ folder.

I think that with all this stuff, we don't have to rely on any comment. On
top of that, relying on comments makes our Crontab file non standard, and
this is something that we really must avoid (think of a user using sometimes
address@hidden and KCron, what will be the result? Does KCron keeps comments?)

Xavier

-----Message d'origine-----
De : Julien Olivier [mailto:address@hidden
Envoyé : jeudi, 13. novembre 2003 21:50
À : address@hidden
Objet : RE: [Pyatcron-devel-list] Cron backend: a correction


On Thu, 2003-11-13 at 18:05, Xavier Nicolovici wrote:
> Julien,
> 
> We are not re-implementing a Cron or At daemon. If the cron task or the
> at commands does not provide a functionality, then simply forget it for
> the moment.
>
> Instead, we could think of predefined tasks that will do the trick, but
> this is out of the scope of this project.
> 

I agree. What I was saying is that we _could_ provide a _plugin_ that
would do that. Like you say, a predefined task. But that's not what the
project is about IMO. More on this just after that ->

> I have one remark about all that is currently said on this list. We do
> not have any list of requirements or items to implement. As of today,
> I'm a bit lost within all we would like to implement. Does anybody here
> could list what we want to implement, from a user perspective?
> 

-> And here is what I think we should focus on:

We should build a _framework_ to create cron tasks. That means that, for
the moment, we shouldn't care about which tasks we want to make it
possible to implement. In theory, our plugin-based framework should
allow to create any type of task, from the simplest to the more complex
ones.

Here is how it works:

Each task is composed of 2 entities: a "command" entity and a "schedule"
entity.

 - The "schedule" entity is common to each task type. It is defined in
the assistant's third page. Basically, you configure it by choosing
between "one-time" task or "repetitive task" and choose the date(s).

 - The "command" entity is more complex. Each type task will have a
getCommand method and a certain number of properties. The getCommand
method will generate the command line using the given properties. The
second page of the assistant will be generated to match the properties
to configure. It's dynamic.

Each newly created task will then be written in the crontab file, as
well as a commented code, allowing pyatcron to rebuild the task in the
UI. For example, we should write, in the crontab file (commented), the
type of task, and the values of each property.

That's for newly created tasks.

For already existing tasks, not created using pyatcron, and thus not
having the commented part, we should fall-back to the command-line
plugin. We would simply show the task as a command-line task using the
command line found in the crontab file.

Does it make sense ?

It might sound complex, but I think it could work :)

-- 
Julien Olivier <address@hidden>


_______________________________________________
Pyatcron-devel-list mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/pyatcron-devel-list

This e-mail contains proprietary information some or all of which may be 
legally privileged. It is intended for the recipient only. If an addressing or 
a transmission error has misdirected this e-mail, please notify the author by 
replying to the e-mail. If you are not the intended recipient you must not use, 
disclose, distribute, copy, print, or rely on this e-mail.
We take reasonable precautions to ensure our e-mails are virus free. However, 
we cannot accept responsibility for any virus transmitted by us and recommend 
that you subject any incoming e-mail to your own virus checking procedures.