On Monday, June 23, 2014 9:32:36 PM UTC-5, henrik lindberg wrote: > > On 2014-23-06 21:48, John Bollinger wrote: > > > > > > On Monday, June 23, 2014 7:45:05 AM UTC-5, henrik lindberg wrote: > > > > > > I see this as an essential feature to support maintainable modules. > > And by "this", I mean a mechanism that decouples the wanted Element > and > > its Container (where the Element is the thing we want/need/require, > and > > the Container is the named thing it is in, typically a Module). > > > > > > > > Agreed. > > > > > > > > This can be achieved by modules describing their provided and > required > > capabilities. These are described as name spaced names and they are > > versioned. > > > > > > > > That's so easy to say, yet so fraught with difficulties. In particular, > > the biggest issues I see revolve around the meanings of capability > > names. Capability names defined and maintained by the modules that > > require them present a potential problem because capability provider > > modules can't be expected to know and declare all the capabilities that > > they in fact provide. > > > Well, they do provide everything in the module. The publishing tool > would extract those as puppet capabilities i.e. class x, resource type > y, function f, etc. (each in the module's namespace). >
Sure, but relying on capabilities declared and discovered that way does nothing to achieve decoupling element from container. In fact, it's what we have now. > > A module that accepts "plugins" declares a required capability > (typically an optional requirement) - i.e. the module supports > additional things, special things if the optional requirement is > fulfilled. It may also have hard requirements. > > I think plugin-style capabilities are mostly a mid-term future consideration, if that. The OP was looking more at a way to express hard requirements abstractly. He couched it in different terms, but that would be the result if it were possible to cause one capability name to be an alias for a different one, as specifically proposed. > This works well in practice in the Eclipse ecosystem with many thousands > of components and requirements spread across a large number of projects > (several hundred at Eclipse itself, and thousands elsewhere). > > Yes, but Eclipse has some significant differences from Puppet. Among the more relevant are 1. The overall architecture of the product is basically a tree, organized around plugin-style extension points, whereas a Puppet catalog is more of a loose mesh, with validity/consistency constraints instead of extension points. 2. Eclipse can and does rely on Java interfaces to express the semantics of demanded of extensions / plugins, but Puppet has nothing comparable. Really, I think the infrastructure needed to support plugin-like module extension points is pretty much orthogonal to that needed to support abstract capabilities. It does make sense for a module that supports plugins to control the associated identifiers and specifications, but that's not where this thread started, so I'd like to avoid going too far in that direction. For abstraction of capabilities, on the other hand, it does not cover all the interesting use cases to require that the component providing the implementation declare the abstract capability(-ies) provided. 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/adadcf2d-46dc-44ac-9157-559ab3703d10%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
