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? M On 03/15/2012 12:19 PM, Erik Mouw wrote: > On Mar 15, 2012, at 09:52, no-re...@cfengine.com wrote: >> I have been thinking about the issue of metadata for bundles, e.g. such as >> author and version, and have been through a number of alternatives in my >> head, >> The problem I have with each of them is that they either change syntax in an >> ad hoc way to something that is not a natural promise, or they separate the >> metadata into a separate body. Neither of these seems acceptable. >> >> My best answer, which requires no immediate feature implementation is to do >> this by best practices, using reserved variables. >> >> vars: >> >> "bundle_author" string => "kermit"; >> "bundle_version" string => "1.2.3 frog legs"; >> >> These are private and can then be used as variables, and examined using >> functions $(bundle.bundle_version) for validation. >> >> Comments? > Hi Mark, > > I welcome that you have thought about versioning of bundles themselves! The > "version" > control promise is too broad to version a CFengine installation, especially > when you > import promises from several master servers: the control promise comes from > server A > and has version 42, and it imports bundles from server B which in its control > promise > has version 463. The client spits an error in a bundle from server B but > prints 42 as > version. That is confusing and having per bundle versions would decrease that > kind > of confusion. > > The problem I have with introducing reserved variables, is that there will > always > be -somebody- who actually uses them in an existing promise, and no matter how > well you have thought about the consequences, the introduction of reserved > variables > will break things in ways you never envisioned. > > In my opinion it would be better to introduce an optional "metadata" promise > type. > In that way you wouldn't break existing installations. Something like: > > metadata: > 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!"; > > Once you have introduced that in the language you can start to use it. You > can start > with printing the version in error messages, but a nice feature would be to > be able > to require certain known good versions of bundles, which requires a way to > compare > version numbers. In the open source world we all love long and complicated > version > numbers (v1.2.3-pre4-beta5), but that makes it hard to compare versions: if > "better > than '1.2.3 frog legs'" is required, how would you tell the system that > '1.2.3-rc1' > satisfies that requirement? I think the only way to solve that is to require > that > the version metadata promise is either something numerical (int, float) which > makes > comparison easy, or you make it a string and use strcmp() to compare versions. > Both ways have their pros and cons, but from the principle of least surprise a > numerical version has the least amount of corner cases. > > Food for thought, hope this helps :-) > > > Regards, > > Erik > -- CTO and Founder CFEngine http://www.cfengine.com http://www.markburgess.org _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
