Re: [Pyatcron-devel-list] Plugins and classes

[Julien Olivier]

On Wed, 2003-11-26 at 17:39, Brian Dee wrote:
> I remember in one of the emails on the list someone mentioned to me that
> you all had discussed how plugins will work before I joined the group.
> Can anyone explain what you had talked about to me?

Basically, the idea is to have a GenericTask class and several
sub-classes of it. Each sub-class is a plugin, in the way that it can be
added/removed without modifying the main program.

For e clear example of what we mean, look at Redhat's config tool for
the network. When you configure a new network, you have to choose
between Modem, xDSL, Ethernet, CIPE etc... Each connection type is a
plugin and is located in
/usr/share/redhat-config-network/netconfpkg/plugins. We want to do
something similar.

In the diagram, FtpDownloader and Archiver are 2 sub-classes of
GenericTask. They are 2 examples of possible plugins. Each one will have
its own properties. For example, an FtpDownloader sub-class will have an
"URI" property to define the address of the FTP site, a "login"
property, a "password" property, maybe a "port" property, and a "local
path" property to define where to download the file. An Archiver
sub-class would have a "compression method" property to define whether
we want to use GZ or BZ2 to compress data, a "backup path" to define
which directory to save, a "archive path" property to define where to
save the generated archive etc...

Each sub-class (FtpDownloader, Archive...) will also have an associated
bash script. For example, there will be a FtpDownloader.sh file and a
Archive.sh file. Each bash script will perform the desired action,
taking the sub-class' properties as parameters.

For example, let's consider the "Archive" sub-class. If you set the
"compression method" to "TGZ", the "saved path" to "/home/bob/important"
and the the "archive path" to "/home/bob/BAK/", the generated cron job
will look like that:

"* * * * * bob /usr/share/pyatcron/plugins/sh/Archive.sh TGZ
/home/bob/important /home/bob/BAK"

And the /usr/share/pyatcron/plugins/sh/Archive.sh would generate the
"tar cvfz /home/bob/BAK/20031201.tgz /home/bob/important" command from
the parameters "TGZ", "/home/bob/important" and "/home/bob/BAK".

We also need a way for each plugin to be "discovered" at start up.
Meaning that when pyatcron starts, it should scan the "plugins"
directory and find all the GenericTask sub-classes defined here (this
directory would contain, for example, FtpDownload.py, Archive.py
etc...).

Finally, the plugins are used to define the command part of each cron
job, not the schedule part.

>  I've altered my
> original CrontTab class to become the ScheduledTask class as shown in
> the DIA diagram for the most part. But, I'm not sure what you mean with
> the setTask method.

First thing, the ScheduledTask class has been renamed Sheduler in CVS.

The setTask method defines which task is associated to the Scheduler. To
sum up, a Scheduler define when the task happen. And the Scheduler has a
"task" property, which will be defined by the setTask method and will
point to a GenericTask object.

For example, you will create a Scheduler running every day at 4am, and
associate a previously created "Archive" object to it using setTask. The
result will be a scheduled archiver.

>  I'm also unclear about pretty much the whole
> GenericTask class. What's it supposed to do? What is the "parameters"
> attribute for? getExecCommand?
> 

It has been modified too. The new class definition should be in CVS. As
I have problems with CVS these days, I attached the latest version of
the diagram that I have on my hard driver. I'm not sure if the version
in CVS is more recent though.

What you have to understand about the GenericTask is that it's only a
generic class that should (in most cases) be overridden by one of its
sub-classes (Archive, FtpDownloader etc...), except in the case where
the user wants to manually define the command used in the cron job.

The role of the GenericTask is to define the command part of the job.
That's why it has a "getCommand" method and a "getParameters" method. In
the previous example, the task we defined would return the following:

 - getCommand -> "/usr/share/pyatcron/plugins/sh/Archive.sh"
 - getParameters -> "TGZ /home/bob/important /home/bob/BAK"

> Also, I still don't understand why you want to use integers for the
> crontab string. If there is a cronjob set to be run every two hours do
> you mean you would write that out to the crontab entry as
> [0,2,4,6,8,10,12,14,16,18,20,22] for the hours field? Why not just a
> string like "*/2"?
> 

Well, using an integer array just seems easier to manage than a string.
Why do you think "*/2" is better than [0,2,4,6,8,10,12,14,16,18,20,22] ?

My idea is that if, one day, we want to add a filter option, it would be
easier to filter dates if those dates are stored in int arrays rather
than strings.

But in fact using strings or int arrays doesn't make much difference,
especially in an easy language like python.

So, if you have good reasons to prefer string to int arrays, i don't see
any problem changing that.

> Just trying to make sure I see things the way you all do!!! :)
> 

You're right. Everyone, please feel free to comment on what I wrote if
you think I also misunderstood some things.

> Thanks!
> 

You're welcome.

-- 
Julien Olivier <address@hidden>

class-diagram.dia
Description: application/dia-diagram