cfengine-develop
[Top][All Lists]
Advanced

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

Re: [Cfengine-develop] Development plan / meeting


From: Luke A. Kanies
Subject: Re: [Cfengine-develop] Development plan / meeting
Date: Fri, 28 Feb 2003 16:05:54 -0600 (CST)

On Fri, 28 Feb 2003 address@hidden wrote:

> > Right, I'm aware of cfengine's dual personality; my point was that if we
> > focus more on the language aspect of cfengine, we'll have a more flexible
> > and thus more usable tool.
> >
>
> Just don't try to turn it into an imperative shell/perl language. That
> is a waste of time and breaks all useful properties of cfengine

I emphatically do not want to do so.  As far as I can tell, all of the
recommendations I have made, and all of the goals I keep in the back of my
head, are completely in line with cfengine's design goals, and maintain
cfengine as a convergent, state-based language (or however you would
describe it).

To me, these features are more about unleashing more of the potential of
this kind of language, rather than converting it to some other kind.  In
fact, some of the features (such as the ability to uses tests like
IsDefined() as lvalues to '::') make the language much more streamlined
and much more obviously state-based; they connect what happens more
closely to what the systems look like, which I think is a feature.

But there are aspects of cfengine the tool which sometimes get in the way
of cfengine the language.  I was thinking about this today, and it seems
to be a good idea actually create a cfagent module to the cfengine
language, and that module would contain most of the tool functionality
(e.g., splaytime, loading keys, defining classes by default, contacting
cfenvd).  Some of it, like loading keys, should maybe be pushed into their
own modules, because I'd like to be able to do things like load the public
keys from a trusted LDAP database.  I'm storing the keys there anyway, why
not take out the middle man (which in this case is just a script that
dumps from LDAP)?

If I'm running a short script to (for instance) make sure the environment
in my home directory is setup correctly, why bother checking the
interfaces (which I can't modify) or attempting to connect to cfenvd?

So no worries on trying to make cfengine into an imperative language; that
would destroy the functionality I want just as much as it destroys what
you want.

Luke

-- 
       First they came for the hackers. But I never did anything
illegal with my computer, so I didn't speak up.
       Then they came for the pornographers. But I thought there was
too much smut on the Internet anyway, so I didn't speak up.
       Then they came for the anonymous remailers. But a lot of nasty
stuff gets sent from anon.penet.fi, so I didn't speak up.
       Then they came for the encryption users. But I could never
figure out how to work PGP anyway, so I didn't speak up.
       Then they came for me. And by that time there was no one left
to speak up.
                -- Alara Rogers, Aleph Press




reply via email to

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