RE: Need 'UncommentAndSetValue' or some such

[David Masterson]

Mark Burgess wrote:
>> 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)? 
> 
> When you say protocols I wonder if you mean like SNMP, i.e. network
> only. Most of the work on cfengine has been about how policy is
> implemented. I refer you to the long list of papers. On the website.

Possibly I use the wrong word here.  I don't mean protocol as in network
protocol.  I mean protocol as in the rules to follow to implement the policy
(ie. a more generic definition).  Basically, I'd like to see a vast library
of cfengine "protocols" that any new user could call in setting up their
policies.
 
> As a generic reply to the editfiles debate:  I have been giving this
> much thought. The point, as identified by several, is that files have
> different formats. (In CS lingo, they form different
> languages/grammars). That means you need editing tools that can
> understand those grammars in a typed way. As of now, cfengine
> editfiles was meant for Unix line based editing. But what about
> things like XML which have context free grammars (parenthetic
> structures). That requires a diffent model.
> 
> At LISA, Aeleen Frisch and I will be presenting our proposal for
> cfengine 3 syntax and data model which will allow cfengine 3 to
> accomodate all these issues. If you want to read up in advance, go to
> the svn server and choose project "cfengine 3". There's a pdf in the
> svn repos with a fifty page theoretical discussion about all this.

Hmmm.  Why don't you post this on the website?  Is there instructions
somewhere on how to get to the SVN repo?

I hope that the cfengine 3 language syntax will be completely LALR(1)
specified and, so, completely parseable by YACC/LEX.  I think it would make
the language easier to understand.

-- 
David Masterson
VMware, Inc.
Palo Alto, CA