On Monday, June 17, 2013 9:32:36 AM UTC-5, Alessandro Franceschi wrote: > > Puppet is a language and so people do the same things in different ways, > and they all work and do what they are supposed to do. > But if we think about modules REUSABILITY and INTEROPERABILITY some > patterns have to be followed. > Some of the parameters described in the document are somehow REQUIRED, > IMHO, if you want to make a really reusable module (for example the ones > that let you decide how to manage your configuration files... if you > enforce a logic in a module or a specific template and don't allow override > by users, then you are not making a reusable module, so for example a > parameter like "template" is just needed). > So, since, at least some of, these parameters are needed for a reusable > module it's just a matter of defining few naming conventions (and managing > external modules dependencies in a sane way) to make different modules > happily live better together. >
Although I agree that to be reusable, modules need to provide certain types of levers, knobs, and switches, as appropriate for their scopes, I think the case is weak for those controls needing to be called by the same names. At best, naming conventions for such things might improve *ease* of (re)use for some people, but the key factor for reusability is not the names of the controls so much as their presence in the first place. I see implications for interoperability only insomuch as one imagines facilitating one module being a drop-in replacement for another, but (1) there's a lot more to that than just common naming, so (2) that kind of interoperability is unlikely to come about except by specific intention anyway, so in that case shared naming comes out as a project requirement. To me, that moots any general parameter-naming standard as far as interoperability goes. None of that is a fundamental reason to object to the effort, but I'm not seeing any promise of significant benefit to motivate me to participate actively. I do have a bona fide objection, however: although the effort is cast at this point as being aimed exclusively at parameter naming, by implication it also covers elements of module structure, organization, and style as well, as the things being named have to exist for the standard to be relevant. I do understand that the intention is not to make all the standardized controls mandatory for every module, but for those that a given module does provide, even the standard's limited reusability and interoperability goals are not served if those controls are not located where the standard anticipates (which is for the most part on a single front-end class). Personally, I would rather see a white paper explaining what kinds of controls need to be available to facilitate reusability of various kinds of modules, and, optionally, setting out one or more models of how a module can provide those controls. Regardless of the nature of the paper's authorship, this feels like it should be a position paper, not a proposed standard. John -- 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.
