fai/class separation

[Niall Young]

On Thu, 16 Jan 2003, Thomas Lange wrote:

> >>>>> On Thu, 16 Jan 2003 14:44:57 +0800 (WST), Niall Young <niall at chime.net.au> said:
>
>     > I'm new to classes :-) but as an extension to bundling all of a
>     > class's components together - what would be the best way to
>     > separate the builtin FAI classes from user defined classes?  Or
>     > is it assumed that the whole FAI_CONFIGDIR/* will be customised
>     > completely?!?
>
> mechanism is very simple. It's just a ordered list of class names,
> which defines a priority inside the classes. Using more complex
> scripts and using inheritance or dependencies makes the whole
> configuration task complex. I think it will be very hard to have
> controll over all the dependencies you are creating inside the classes
> and scripts. What about testing (oooh testing takes a lot of time)
> this huge moster of classes and scripts in /fai/scripts. Do you think
> these scripts will work in all situations of defined classes when
> classes create dependencies?

I agree, but if done properly it would be no more complex imo.  In fact,
I think class creation and inheritance would be much easier with a
defined spec file as discussed previously.  Configuration of these
classes will always be where the work is, for a newbie the current
class system is more vague (complex) than it has to be imo.

> My preference is: Keep it simple!

I agree entirely, I didn't think I was proposing anything outlandish.
If we change small mechanisms like the order in which classes are
defined, the order in which scripts are executed - it shouldn't change
the default behaviour if you're not interested in those features.  If
you are, they're there to use.  It could be as simple as parsing a
Depends: line and moving a class to the end of the queue.  If the line
doesn't exist, continue as normal.

>     > I'd like to keep my own classes as separate as possible and not
>     > touch the builtin classes and scripts if possible.  Something
>     > like:
> But you will always have the freedom to define the classes as you
> like. It you dislike fai-class, just write a hook
> task_defclass.DEFAULT and you can do whatever you want.

Yes but I'd rather we work towards a common goal and benefit from each
other's contributions.  The class system is infinitely flexible, yes,
but giving it *some* structure can't be bad.  Increasing the base
features, promoting examples to 'standard'/optional features doesn't
take away anyone's ability to ignore them or override them with hooks.

Why not start an open ended thread here to reach a consensus on the
most useful 'features' that people want in their classes?  Once we know
what everyone wants we can improve the class structure and work on
implementing these features by consensus so they're generic and useful
to as many people as possible.  Why leave everyone to re-invent the
same wheel on their own?

Niall Young                                    Chime Communications Pty Ltd
niall at chime.net.au                            Level 6, 263 Adelaide Terrace
Ph: (+61) 08 9213 1330 / 0408 192 797         Perth, Western Australia 6000

     "there's a lot of movement in my trousers at the moment"
                                     -- Dennis Kristofich, Sep 2002