On Thursday, June 20, 2013 4:12:46 PM UTC+2, jcbollinger wrote:
>
>
>
> On Wednesday, June 19, 2013 5:34:58 PM UTC-5, Alessandro Franceschi wrote:
>>
>>
>>
>> On Wednesday, June 19, 2013 5:03:41 PM UTC+2, jcbollinger wrote:
>>>
>>>
>>> Call me "experienced", "jaded", or even "cynical", but I know of too
>>> many instances of vaporware to be swayed by promises of software that
>>> hasn't yet been written.
>>>
>>
>> I just call you cynical. We can't do anything if we don't try to do it.
>>
>>
>
> By all means, do. If you are somehow getting the impression that I object
> to the project then I apologize. Indeed, I encourage you to proceed, and I
> wish you well. I just have low regard for software that doesn't yet
> exist. I do not find the potential for nebulous future software a
> persuasive argument for adopting anything.
>
> What I actually object to is misrepresentation -- even though accidental
> -- of the nature and scope of the project. It is NOT restricted to
> choosing names.
>
> Secondarily, I object to positioning the effort as a standardization
> project, and I advise you to position it differently. Names and labels are
> meaningful. How the project proceeds, who participates, what they propose,
> and all manner of intangibles will be influenced by your decisions in this
> regard. Frankly, I am inclined to resist a "standardization" effort from
> any random third party, but I have no reason whatever to oppose anyone
> drafting a set of conventions or best practices. After they have been
> tested in the field will be a suitable time to consider standardization or
> endorsement.
>
>
>
>> *A really reusable module HAS to be parametrized*.
>>
>
>
> Utter hogwash.
>
Lol. Show me a real example of a reusable module without parametrized
classes that at least manages a typical package/service/configuration file
scenario.
Give me proofs, not words that I have to search on a dictionary.
>
>
>
>> Take note, I can repeat and argument that anytime.
>>
>
>
> Then no doubt we'll be hearing from each other on this again.
>
>
>
>> Parameters are the API of a module, the interface you can interact with
>> it without touching it.
>> If you don't use parameters either you are forcing inside the module
>> behaviours that can't be changed by users or you are forcing a specific way
>> to obtain the data that affects the modules behaviour and this inherently
>> makes it not reusable for people who provide data in other ways.
>>
>
>
> The data consumed by a module and the labels by which they are identified
> are certainly parts of a module's API, but it is by no means necessary to
> express those or interact with them in the form of class parameters. You
> cannot safely use parameterized-style class declarations (as opposed to
> class *definitions*) of any API class, especially in or with modules
> intended to be interoperable. That makes parameterization largely moot as
> far as reusability goes. If people want to parameterize their classes then
> I have no special reason to object. I do object, however, to the premise
> that doing so usefully improves reusability or interoperability, and
> therefore I object to any proposal that expressly calls for classes to be
> parameterized.
>
> As long as we're talking about standards, Hiera is Puppet's de facto
> standard interface to external data. It is usually expected that proposed
> standards will build on other, existing standards, whether de facto or
> formal.
>
Sadly, Hiera is not the only de facto standard interface to Puppet's
external data. Variables set via an ENC are another widely used "standard".
Also I'd say that Hiera is standard with Puppet 3, not with earlier
versions.
So please show me a reusable module without parameters and without hiera
functions inside, as that would not be reusable by whoever does not use
Hiera.
> I think your proposal would be stronger if it truly did focus on the data
> that might need to be supported by modules and the names / labels / keys by
> which they are identified. If you choose a namespace-based system then you
> can align it to be consistent with class parameterization and automated
> parameter binding, yet not dependent on those. I know you want more, but
> you should consider making a separate effort of the rest.
>
I've no problems in concentrating in naming without "forcing" the usage of
parametrized classes, but still have to figure out HOW to manage injection
of external data to the module without using parameters (and without using
hiera calls or references to arbitrary fully qualified variables names).
Curiously one of my efforts in the past has been exactly towards this
direction, so I have actually a solution for that, but it still requires a
parametrized class, even if you can use it with a simple include.
>
>>
>>>
>>> Most importantly, however, my central objection here is that a proposal
>>> that purports to be exclusively about naming parameters in fact has any
>>> implications at all for module organization and style.
>>>
>>
>> Ok, it's not a proposal that purports to be exclusively about naming
>> parameters: the usage of specific parameters involve patterns that enhance
>> modules' reusability and interoperability.
>> The sample module code definitively exposes design patterns with modules
>> (and it demonstrates that you can follow different patterns to achieve the
>> same behaviour.
>>
>> Reading it again this is not so clear in the first post here, but it's
>> widely expressed in the linked pages.
>> So, sorry, now let's move a step further, let's talk, if you want, about
>> how to make that paper/draft/proposal better.
>> And if you think that such a thing should not even be discussed, well,
>> ok, I'll accept that and discuss it with who is interested in it.
>>
>>
>
>
> I think it would be better if it actually were narrowed in scope to
> identifying patterns in the data that modules consume, and choosing naming
> conventions for those data. Better, and also easier to reach consensus
> on. Include some comments about namespacing, especially in conjunction
> with accessing data via Hiera. These issues are separate from and more
> fundamental than class parameterization or module organization. They will,
> however, influence anyone who chooses to write modules with parameterized
> API classes.
>
>
No problem in that. The intention is to share naming standards, not to
force people in making modules in a certain way.
Still I keep on thinking that you need parametrized classes to have truly
reusable modules (note that this does not mean automatically that you must
use a class { 'name' : } statement to use them, on my modules you can set
parameters how and where you want (hiera, enc/top scope) and just include
classes that use these parameters.
Show me alternative code and I will gladly change my mind.
al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
