On Tue, Oct 29, 2013 at 3:29 PM, John Bollinger <john.bollin...@stjude.org>wrote:
> > > On Monday, October 28, 2013 4:05:47 PM UTC-5, Rob Reynolds wrote: >> >> >> So, an array then. But an array of what, exactly? Your hash values are >>> already arrays themselves -- whose meanings are largely opaque to me, by >>> the way -- so will you now have an array of arrays? An array of hashes >>> would be more self-documentary, but wait: those inner hashes now bear a >>> strong resemblance to resource declarations. Why was it, again, that you >>> didn't want a separate resource type for ACEs? >>> >> >> Mostly because of resource explosion. https://gist.github.com/** >> ferventcoder/7204591 <https://gist.github.com/ferventcoder/7204591> - >> Note that it is 20 lines to say the same thing in 8 lines. But is it the >> right answer? I think there is a happy medium here we should explore where >> one or both options could live. >> >> > > You achieve 8 lines vs. 20 by choosing a form that favors concision over > clarity (and by your choice of where to break lines). To represent ACEs as > arrays as the example code does, the Acl type must make assumptions about > the order of elements, and it must also either make inferences about the > meaning of other elements based on their values (which is risky), or else > limit which combinations of ACE properties can be modeled (which is > unsatisfying). As for self-documentation, where you started this > discussion, the array representation of ACEs severely lacking. > > A form more like this would be better in all those regards: > > acl { 'c:/windows/temp/some_dir': > inherit => true, > purge => false, > permissions => [ > { identity => 'bob', rights => 'modify', type => 'allow', inherit => > 'all', propagate => 'all' }, > { identity => 'tim', rights => 'read_execute' } > ], > } > > I definitely like this. I had originally started down this path and thought it was too verbose, but seeing it again and after discussing this, I think I like the direction and clarity this provides. It allows ordering among other things. > At least the ACEs are then reasonably easy to interpret (by both humans > and machines), but it's not much less verbose than a form with separate > ACEs: > > acl { 'c:/windows/temp/some_dir': > inherit => true, > purge => false, > } > > ace { > 'bob/some_dir': identity => 'bob', file => 'c:/windows/temp/some_dir', > priority => 1, rights => 'modify', type => 'allow', inherit => 'all', > propagate => 'all'; > 'tim/some_dir': identity => 'tim', file => 'c:/windows/temp/some_dir', > priority => 100, rights => 'read_execute'; > } > > > That's 8 non-empty lines as I wrote it, btw, if you really want to use > such a metric (a token count would be less style-dependent). Plus all the > parameter values have simple types, which I think is a big usage win. > > You mentioned concern about a "resource explosion", but I don't think the > example actually went there. Keep in mind that a major objective of the > modern form of ACL inheritance was to minimize the number of distinct ACE > objects in the system, keeping them toward the root of the tree, with the > happy result that the main cases for Puppet to address involve relatively > few ACLs and ACEs that actually need to be managed. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/67e7a0c6-29f5-4227-a49f-d3aee19f508f%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- Rob Reynolds Developer, Puppet Labs Join us at PuppetConf 2014, September 23-24 in San Francisco -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMJiBK7ygtdMr%2BQ2NH1uKRTA%3DObEHZO8ahCX6vbPEP4Wor_Crw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
