Re: [Cfengine-develop] Development plan / meeting

[Luke A. Kanies]

On Fri, 28 Feb 2003, Mark Burgess wrote:

> We need a procedural checklist:
>
>  - is it gratuitous functionality or of general interest?
>  - is it convergent?
>  - does it confict with existing code/principles?

I definitely agree, and I think that these principles should be clearly
documented for the developers.  We will have to keep them up ourselves,
but that way it's much easier for more people to contribute in what ways
they know how, rather than relying on a monolithic development style where
fewer know the reasons decisions are made.  I know that the design
principles of cfengine are relatively clearly documented, but that's not
the same thing as the code design.

> I think cfengine needs to stay as small as possible. I agree that
> many command-line options can now be eliminated. All tidying is
> useful.

I think it could get a good bit smaller, or at least it seems that way to
me.

I would _love_ to see a more sophisticated module interface developed, one
which let anyone develop modules which could be configured similarly to
existing cfengine sections.  Then, I'd really like to see most of the
existing cfengine sections moved to modules, _including_ the core cfengine
configuration stuff.  Just like how Apache has core modules for all of the
config stuff.

This would require pretty significant modifications to the parsing,
though, and it looks like it would be less than trivial to do this and
maintain syntax compatibility.

> A general principle:
>
>  Don't give users what they ask for, give them what they need.

I would add a couple principles:

When possible, treat cfengine more like a language and less like a tool.
This will make it much more generically useful, and will keep the design
focused on providing the kind of consistency one expects in a language,
vs. the allowed inconsistency of a tool.

Design to stay within cfengine as much as possible; if we find that people
are doing things like autogenerating cfengine code, we need to figure out
why and address the design decisions that are forcing that.  I find it
remarkable how many people generate cfengine code, and how many people
consider cfengine a basic building block but wouldn't consider using it as
their main framework.

> Many "complaints" are just not thinking straight.

I agree, but many complaints are also because cfengine makes certain types
of operations far more difficult than they need to be.

I think it would be very worthwhile for some of us to spend time combing
the list archives and figure out what people consistently have to
workaround, and then find ways to design those problems out.

I personally find the lack of real lists, and especially the implicit,
"sometimes" nature of lists, to be very frustrating and something that I
often have to generate code to resolve.

Luke

-- 
If smiling uses so fewer muscles than frowning, how come it
hurts my face so much?