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). > > 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. > > -- > Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | > +1-615-594-8199 > > -- > 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. > > I've talked before about the notion of converting all logic into client-side logic, effectively leaving no server-side logic, but for reasons like "least privilege" it's probably best to shy away from that approach. Our current model (with a few notable exceptions) emphasizes server-side logic. It's my opinion that we should either unify on one side, or find a way to promote both -- clearly! -- to equal status. Adding `onlyif` and `unless` metaparams to all resources may be one way to achieve that. -- 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.
