On 03/15/2012 08:02 AM, Mark Burgess wrote:
> On 03/15/2012 01:07 PM, Nick Anderson wrote:
>> On 03/15/2012 07:01 AM, Mark Burgess wrote:
>>> Thanks Eric, I had exactly the same thought. The problem with this
>>> approach is that introduces "body syntax" within a bundle, which will be
>>> confusing and will weaken the integrity of the language (and parser).
>>> That is my main objection to this.
>>>
>>> What do others think?
>> I agree that specific syntax breaks the integrity and consistency of the
>> language.
>>
>>
>> To keep consistency you could do something like this.
>> metadata:
>>   "$(this.bundlename)"
>>      author  =>  "kermit";
>>      email   =>  "ker...@muppetshow.example.com";
>>      version =>  "42";
>>      purpose =>  "Make sure Miss Piggy doesn't get angry";
>>      comment =>  "Please don't let her read this!";
>>
>> I am not really convinced though
> 
> Yes, the problem with this is that you can only have one promise and the 
> name of it is not open for discussion, so why bother to write it...

I guess the fact that the name isn't open for discussion doesn't bother
me, its specific in what its purpose is and being a separate promise
type I think makes it easier to find/read.

I think what bugs me about it is that the metadata promises could be
anywhere in the policy. If it could not be then it seems like that would
break the integrity of the language as well. Right now I am kind of
thinking that the meta-data should be encapsulated within the bundle so
that it cannot be separated breaking the integrity.

> My other idea was to have a separate body:
> 
> body bundlename meta
> {
> author => "kermit";
> email => "ker...@muppetshow.example.com";
> version => "42";
> purpose => "Make sure Miss Piggy doesn't get angry";
> comment => "Please don't let her read this!";
> }

My feeling on this is similar to the metadata type promise, its not
inextricably tied to the bundle and could be lost. It's one thing for
the metadata to be omited, its another thing completely in my mind to
have "orphaned" metadata/bundles.

> but then this could become inconsistent. The version does not actually 
> label anything, because it is just a pointer not an instance. That 
> brought me back to the idea that a variable would be the best.

I still like the idea of separating the meta-data into its own type for
readability, but I cannot currently see a way to do that without either
breaking the integrity of the language, or leaving the possibility for
orphaned metadata/bundles.

Perhaps instead of reserved string names, a reserved array name.

"bundle_metadata[author]" string => "kermit";
"bundle_metadata[version]" float => "42.0";
"bundle_metadata[email]"  string => "ker...@muppetshow.example.com";
"bundle_metadata[purpose]" string => "Make sure Miss Piggy doesn't get
angry";
"bundle_metadata[comment] string => "Please don't let her read this!";

In my mind, while not completely separate, all the metadata is at least
contained.

-- 
Nick Anderson <n...@cmdln.org>
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Reply via email to