Re: [Pyatcron-devel-list] Backend requirements

[Julien Olivier]

On Wed, 2003-11-12 at 08:58, NICOLOVICI Xavier wrote:
> Hi there,
> 

Hi !

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

That's OK for me.

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

I attached the whole work until now (at least what is on my laptop,
Matthew could have something a little bit different).

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

I agree wholeheartedly.

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

Just a notice: I think some work on the UI can be made in parallel. For
example, the about dialog and the _frameworks_ for both the properties
page and the assistant. That said, it can also be postponed without any
problems.

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

Well, I'm far from being an expert about cron. But from what I've seen,
it seems that the cron jobs that are defined by default in Fedora are
"system" jobs. They belong to root and could not be modified without
having the root password.

So my question is: do we want to be able to handle "system" jobs too ?
Or do we limit our field to "userland" jobs ?

If we decide to handle system jobs, we'll obviously have to mess with
the run-parts stuff. But if we don't, I don't see any reason why we
should use run-parts.

Now, I don't even know how to create a user-land job... but I know it's
possible :)

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

Maybe a stupid question but why can't it be an abstract one ? I mean,
what could a generic PyAtCronTaskType class do ?

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

I agree. However, I think it should be /usr/share/plugin (only 1 'g').
redhat-config-network uses /usr/share/plugins, which can be more logical
as we can expect to have more than one plugin.

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

The best is to look at the code in /usr/share/redhat-config-network.
Especially netconf-tui.py and the code in netcfgpkg/plugins. I don't
have enough knowledge in python to understand all that for the moment
(neither have I really looked at it very deeply). Maybe you can try to
understand it and explain it to us ?

However, here is what I gathered at a glance:

in netconfpkg/plugins/NCDevADSL.py: df.register(DevADSL, DSL)

it seems that each class registers itself using the df.register method.
df is defined here:

in netconf-tui.py: df = NCDeviceFactory.getDeviceFactory()

So I guess the interesting code is in the DeviceFactory class...

What I don't understand though is, how do the devicefactories register
themselves ? I guess the main program simply scans the plugins folder
and calls the classes matching the names of the files found in it.
Maybe...

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

Yes, that was part of the plan.

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

That's what I did. But it might be useful to also create a savannah
account for Brian (the newcomer), and adding it to the project so that
he can send code to the CVS. Or do you want us 3 to keep full control of
the CVS ?

As for the website, I'm thinking of it. But I'd like to make it when we
get something to download (a 0.1 alpha release :))

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

Sorry, I'm not sure I understand. Do you mean that we should write a
kind of user manual, or a HIG for the GUI developers. If you're thinking
of a HIG for developers, isn't GNOME's HIG already enough ?

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

Well, now you've got mine :)

> The next step would be to comment the above,

That's on my TODO for _now_.

>  identifiy needed classes for
> the backend, define them (fields, method), make a pre-implementation and
> link everything to the GUI.

I agree. By the way, I had written an email to Matthew on the mailing
list about the PyAtCronTask. Do you have any ideas on this one too ?

> Do not forget the "run-parts" RedHat approach, we must decide how to handle
> that (both in the backend and with the GUI).
> 

For the backend part, I already anwsered. However, for the GUI, it
should be totally transparent for users. That means, that if we use the
run-parts, we should somewhat "transform" the run-parts scripts in
individual commands and make them appear as tasks using the "shell
command" plugin. But, again, I really think we shouldn't mess with those
admin tasks.

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

Yes, sorry about that.

> 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
-- 
Julien Olivier <address@hidden>

pyatcron.tgz
Description: application/compressed-tar