RE: Comments on the diagram (was: RE: [Pyatcron-devel-list] Cronbackend: a correction)

[NICOLOVICI Xavier]

Julien,

Some answers to your questions

> 
> 1) why do you split ScheduleedTask and GenericTask ? Isn't 
> there 1 (1,1)
> relation between them ? From what I see in your diagram, you seem to
> want a (1,*) relation between. If I agree with it, doesn't it 
> mean that
> the ScheduledTask class should have a task _array_ property, 
> as well as
> appendTask(task), prependTask(task), removeTaskById(Id) and
> getTaskById(Id) or something like that ?

You're right, the relation between GenericTask and ScheduledTask should be 
(1,1). I've used the (1,*) first because I was thinking about the possibility 
to have many tasks planed at the same time, but this sounds a bit complicated 
to implement. Let's do it (1,1) for the moment.
Matthew, if I'm not wrong, you've said that you wanted to write those classes. 
Would you mind follow the class diagramm we have now and submit any comments 
you may have?

> 
> 2) In the ScheduledTask, I think that it should be arrays of minutes,
> hours, days etc... as you can specify several dates for the same task.

Yes, that's true. Those fields should be arrays of integers. I'll update the 
diagram.
 
> 3) I think the GenericTask should have functions like addParameter and
> deleteParameter. It should automatically generate the execCommand from
> it's sub-class properties. For example, an Archiver class, 
> sub-class of
> GenericTask would have a "archiverCommand" property as well as a
> "pathToBackup" property. Now, calling the getExecCommand 
> would generate
> the "tar cvfz /tmp/pyatcrontmp645.tgz /home/pollux/important" command
> using those properties.

Absolutely yes, sub-classes of the GenericTask should add their own fields and 
methods. The most important for sub-classes is to overide the getExecCommand 
and getExecParameters abstract methods of GenericClass. Now, why having 
getExecCommand and getExecParameters? Well, there is no reason in Python as we 
can use a single string with command + parameters to launch an external 
software. I've splitted both because of my long, long, long experience in C 
coding, where the exec syscall expect those to be separated (at least, if you 
want to be POSIX compliant).

> I think that's all :)

Hmm, I don't think so. I didn't found any class diagram updated with your 
comments ;-) Don't worry, I'll do it
 
> BTW: thanks for your work. The diagram is a good idea, as well as the
> docs in CVS.


I would like to take this opportunity to say something. In the first days when 
this project was born, I was impressed how fast you've written code, without 
any analysis. Now, after a week or two, I would like that we first try to draft 
some UML schema and/or write specs before starting to code the software. I know 
that this is boring, but it's the only way to have materials to discuss on and 
a clear view of what to do in short term. Trust me, more documentation we have, 
easyer will be coding and maintenance.

Bye everyone and thanks for your support,

Xavier

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.