pyatcron-devel-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Pyatcron-devel-list] Cron backend: a correction


From: Childers, Matthew
Subject: RE: [Pyatcron-devel-list] Cron backend: a correction
Date: Thu, 13 Nov 2003 16:12:01 -0600

 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 :)


This is exactly how I was thinking.  We have to have a
command-line/default "plugin" for the cron jobs that already exist.  And
then use comments in the crontab which we would parse to call the
correct plugin when they edit it.  I also like the idea of the
getCommand method.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]