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

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

[Pyatcron-devel-list] Backend requirements


From: NICOLOVICI Xavier
Subject: [Pyatcron-devel-list] Backend requirements
Date: Wed, 12 Nov 2003 09:58:59 +0100

Hi there,

I've been through your long long emails about the UI, and it seems that you
guys are better than I on GUI design (the truth is that I miss an artistic
mind, something related to my left brain... ;-) I will certainly let yon
work on this.

Appart from that, could I ask someone to send me the glade file, I've only
got the Pyton code. Thanks.

Ok, now let's talk about the software structure. UI is good, but without a
strong backend, it's useless.

Here is the task I think we should focus a bit before going deeper in UI.
Remember, comment what I'm writting, I'm not a pure genious and you MUST
make comments and point out errors ;-)

1. How should we manage the cron entries. Cron uses a structured config file
that let us write entries directly in it, but RedHat has introduced the
concept of daily, weekly, monthly and yearly cron jobs (to explain a bit,
daily cron entry is a script that runs daily the scripts present in
/etc/cron.daily, same for the three others). The script used in the cron
entries is /usr/bin/run-parts.
The question is, do we want (or do we must) to handle this "run-parts"
approach? If yes, how could we reflect that in the UI? How this will be
merged with our own task management?
Remember that Fedora comes with a bunch of predifined "run-parts" jobs, and
ignoring it might makes the software a bit useless for new users.

2. Pluggin structure. To create predefined task, thinking in object oriented
development, we should defined a super class that will be parent of all the
predefined task class. This class should not by an abstract one (meaning
that we should be able to instanciate it), but provide basic methods to
build a task and register it in the crontab.
Then, if some external coders would like to develop a new predefined task
(ie a pluggin), they will have to inheritate from this class and specialize
some of the functions. This new class will have to be declared somewhere
(/usr/share/pyatcron/pluggin for example) to make it available for the main
software.
Question: How could we register new class in Python? How can we instanciate
new class at run time (ie without knowing its name when writing the code)?
What kind of pluggin declaration should we used (I've seen in you emails
that redhat use same approach for the network interface control, I'll have a
look at it).



3. I think that the superclass defined in point 2 should be directly linked
to the UI. In other words, each entries of any list in the UI should be
linked to an instance of this superclass. That way, when launching pyatcron,
the first thing to do will be parsing the crontab file (and any run-parts
modules), initialize superclass objects for each entry found and store them
into a GtkList (or any kind of list available in Gtk).

That's all for the Pyatcron backend.

Some other answers:

* If new people would like to join, no problem, simply tell them to join us
on the devel list (to register:
http://mail.nongnu.org/mailman/listinfo/pyatcron-devel-list). This kind of
information might be usefull on the project home page. Julien? ;-)

* While coding the UI, trying to write down a user huide at the same time is
a good approach. This let other people knowing where we are going, and help
them joining the team. I know that this is called the "dark-side of coding",
but aren't we Free Jedi's ? ;-)

Ok, let stop writing for today. I'll wait on your feedbacks before making
some architecture proposal.

The next step would be to comment the above, identifiy needed classes for
the backend, define them (fields, method), make a pre-implementation and
link everything to the GUI.
Do not forget the "run-parts" RedHat approach, we must decide how to handle
that (both in the backend and with the GUI).

Regards,

Xavier Nicolovici


PS: Last but not least, try to use subject that macth your message, it makes
archive search easier.

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.











reply via email to

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