RE: [Pyatcron-devel-list] Backend requirements

[Childers, Matthew]

> -----Original Message-----
> From: NICOLOVICI Xavier [mailto:address@hidden
> Sent: Wednesday, November 12, 2003 2:59 AM

You sure do get up early, you sent this at 3 AM.  :-)

> To: address@hidden
> Subject: [Pyatcron-devel-list] Backend requirements
> 
> 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.

I think this is where we have to decide, do we want to make this a task
scheduler for a user's individual crontab, or do we want to allow them
to handle all cron tasks?  If we do start handling the run-parts, then
we will need to implement PAM for authentication (as Brian said), just
like rh-config-network, rh-config-packages, and many others do. Or what
about making the main interface handle users crontab, then have either a
preference that allows them to switch into the "Advanced Mode".  This
would then prompt them for the root password (if they are running it as
a user) and then populate the list with the jobs in run-parts.  And we
would use a plugin to handle the modification of those jobs.  Just a
thought, what do you all think?  Shouldn't have to modify the UI much to
do it that way.  If not, we could always start out just offering
modifications to the users crontab, and then maybe later look at
handling the system jobs.

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

I'm not going to lie, in that I understood very little of what you are
saying, simply because I am not familiar with a lot of the OO terms.
However, from what I am picking up, I like the idea of creating a super
class, that other developers could inherit from.  It looks like Julien
might have already found the answer to the registration question.


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

What about a Task class that would inherit the superclass you talked
about earlier and a schedule class?  I may be way off here, so if I am,
please point out my problems, I won't learn if you don't show me where I
am wrong.  :)


> 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 ? ;-)

I'm not sure I know what you mean when you say a user huide, do you mean
commenting?

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

I would say lets first focus on the userland jobs and with our plugin
structure, we should be able to handle the system jobs fairly easily
once the rest is in place.

> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Pyatcron-devel-list mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/pyatcron-devel-list