On Saturday, June 22, 2013 11:47:13 AM UTC+2, Wolf Noble wrote: > > > I'd like to say I really like the intent behind this. > > Yes, a name is important. So is continuity. I believe the underlying goal > is to provide a collection of reference material. Once the skeleton of this > material is generally agreed upon, it can be used as guidelines to the > community for how to implement a common set of functionality with > performance, and the greatest quantity of interoperability in mind. > > How is this a bad thing? > > The demonstrated example shows plenty of well thought out functionality. > How might we better implement these functional knobs and levers? >
Yes, that's the kind of things I'd like to discuss. > > Lets go beyond the fact that the only reason we call knobs, switches, and > levers what we do is that communally we agreed that this long-ish thing > protruding from this surface over here should be called a lever, that this > definitive state toggle be called a switch, and this round, grabbable > twisty thing here should be called a knob. Names are important, but not > just because they're names, they're icons of functionality. > > Consistently referring to a lever as a lever provides more intuitive > context, but doesn't change how it operates. Does it do the same thing if > you call it a widget? Sure! Does it help with the goal of communally > establishing conventions of grounding and interoperability? Not so much. > > So, on the one hand, no, this conversation is not purely about naming > conventions. On the other, I don't think that's the point to focus on. > > I can absolutely see the value in a few sets of versioned > "interoperability reference" modules, which provide one a good working > model of how to provide specific bits of functionality in as flexible a > manner as necessary. > > There are several different good module paradigms out there. I feel that > fragmentation of design and implementation hinders the community more than > a little bit. It confuses it, at the very least. > > I do not believe a 'one-size-fits-all' paradigm would do us all that much > good here either. You'd likely always be one side or the other of too much > scaffolding for simple modules, and not enough flexibility for complicated > ones. > Agree. > > I believe this means a few levels of module complexity would need to be > modeled. Then the transitions between those states would be more > straightforward. Someone could expand the functionality of your module with > greater ease and consistency. > Totally agree. > > I would love to see other examples which provide similar levels of > implemented functionality. > Actually it would be interesting, and actually is something that is definitively planned, to explore, different sample modules for different kind of applications: for example Java/Rails apps, or more complex cases, where you need defines but maybe also types and providers, also to validate and test the naming and functional choices. > (... (:(: and then the bikeshedding and performance holy wars can really > get going :):) ...) > > What other good ways are there to easily write unit tests to validate the > different behaviors of a module without parameters? > Facts? > Limited scope/functionality subclasses? > I still can't figure out how to make a reusable module without parameters and without explicit hiera calls inside. I'd really be interested in seeing an example. > This is a very exciting subject of conversation. I am thankful to everyone > participating in it for their thoughts and contributions. > I'm looking forward for your suggestions on: https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA 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.
