On Thu, 27 Oct 2005, David Masterson wrote:
> Now if it could only be abstracted...
>
> I think CFEngine implements two things -- policies and protocols. Policies
> are the answers to "what type of system is this?" Protocols are the answers
> to "how do I implement a policy?" My question is has anyone given thought to
> producing generic protocols for CFEngine that could be used everywhere
> (within the assumptions of the protocol)?
Well, I can certainly testify that much thought has been given to such
things, but I have never been in a room in which it was being discussed
where there was any clear agreement on those two terms.
One of my main priorities in Puppet was to draw a very clean line between
the language, which is all about expression, and the library, which is all
about action. There's basically a three step conversion from the text-based
configuration to objects (because I'm writing in Ruby, it's all objects)
that can manage the system:
1 - parse the text
2 - a client connects; interpret the appropriate parse trees and generate a
portable configuration (an extremely simple object type, could easily be XML)
3 - the client takes this portable configuration and turns it into objects
in the library
So on the one hand it wouldn't be that difficult to, say, use the Puppet
language and parser to generate a cfengine configuration, as long as you
wrote a simple translator from my portable objects to cfengine (which would
be nigh on impossible for editfiles, and difficult for control and groups,
but easy for any of the object-like types).
But I think you're probably talking about a language-level separation, not a
language/library separation. I've written some decent constructs within
Puppet to make that easier, so I'd be interested in hearing whether they
meet your needs.
That being said, that obviously doesn't really answer your question, since
I'm sure you're looking for cfengine to acquire these things, not for some
other tool that might have them. I can't really help with that, although
I've tried before.
--
I conclude that there are two ways of constructing a software design: One way
is to make it so simple that there are 'obviously' no deficiencies and the
other way is to make it so complicated that there are no 'obvious'
deficiencies.
-- C.A.R. Hoare, Turing Lecture "The Emperor's Old Clothes" CACM
February 1981, pp. 75-83.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
