On Tue, Oct 29, 2013 at 3:29 PM, John Bollinger
<[email protected]>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' }
>   ],
> }
>
>
> 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';
> }
>
> So type would be file in this case. How would you grow it to the other
types besides files and folders? ie. services, registry, etc


>
>
> 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 [email protected].
> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMJiBK7eO9owcZCY1Ogc48R2FEWnj2oLNpmPB2z1GiioZ%2BdS8A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to