On Wed, May 16, 2012 at 2:22 PM, Luke Kanies <[email protected]> wrote: > On May 16, 2012, at 2:00 PM, Daniel Pittman wrote: >> On Wed, May 16, 2012 at 1:51 PM, Deepak Giridharagopal >> <[email protected]> wrote: >>> On Wed, May 16, 2012 at 2:07 PM, Chris Price <[email protected]> wrote: >>>> >>>> p.s., if we do go down this path it would be interesting to see if there >>>> is some sort of existing library or standard specification for boolean >>>> logic >>>> expressions that we could piggy-back off of, rather than rolling our own. >>> >>> There are also other places in the language that may have similar needs >>> around expressing conditions and selection criteria, such as when >>> collecting/realizing virtual or exported resources. >> >> Those areas do, in fact, define a small boolean logic language already. >> >> Using that elsewhere isn't impossible, but it is a pretty big change >> to the definition of what a property or parameter can mean. >> >> >> In many ways I think that the `tidy` type is the best thing to compare >> this to: it explicitly operates on client-side state, and is distinct >> from the parent type. >> >> The separate "user range" type is the closes analog there. >> >> It seems like that separation is going to have a whole lot less >> unexpected or hard edges than extending the "user" type will. > > People usually compare it to the exec type, which has the onlyif and unless > parameters (and very limited boolean behavior - based entirely on the run > status of a command).
Good catch - that is another example, and appropriately client-side. There has also been discussion of extending those to all resources, not just exec, which is interesting. > As you point out, this is logic on the client, rather than on the server. > > Another related thing that's been asked for is boolean logic that affects how > the graph is traversed - e.g., if A then manage X resource, if B then manage > Y resource. This is an even bigger difference, but still related in that > it's client-side logic. It feels like we need to go some distance down this path, because a number of decisions (provider selection, UID details, etc) are only answerable on the client. I don't know how comfortable I am with the graph traversal changes, but I can see why they might attract. Starting with more resources, or perhaps resource-like-things, that are focused on "group" operations feels like a reasonable first step. -- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
