On Wed, Mar 1, 2017 at 5:46 AM, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:
> > *Big picture items* >> >> *Multiple implementations / implementation selection* >> >> In splitting resources into "definition" and "implementation", the >> proposal adheres to a *form* similar to the current system's, but it >> seems to have fundamentally different design goals. I've always >> interpreted the present type / provider system's separation of resource >> interface from implementation first and foremost as a means to accommodate >> multiple implementations. The one most appropriate to the target system is >> chosen from among those available. I think that's a sound design approach; >> I like it, and it has served Puppet well. As far as I can determine, >> however, the proposal loses that completely -- I see no means to support >> multiple implementations at all, much less means to match an implementation >> to the target system. >> >> > I hadn't actually caught this, but if not just an oversight, it is indeed > concerning. The ability to choose from various providers has been a strong > play in Puppet's favor. > The main weakness of the current system is that the data type for a resource changes based on the provider that is ultimately used for it. Once you use yum-specific attributes in your package resource, it's only going to work with the yum provider, though that might be hard to tell from just looking at the resource. I would favor an approach where you can write a resource either directly to the interface the provider actually implements (i.e., package_yum - use all the yum-specific stuff you want) or a generic/abstracted type interface that is defined so that it can be fulfilled by all the providers for it. To phrase that slightly differently: I've come to look at types and providers as both defining data types for the resources they handle. Providers define a concrete, definite list of the attributes that they handle. Types in that view are an abstraction across multiple providers, and more reminiscent of Java interfaces or Rust traits in that respect. Do you see issues with that approach ? The question of how much work it should be to actually make the abstracted type interface come into being is important, but somewhat secondary to whether that general approach is useful. David -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAHN%2BA%2BX4uRLkPDkoCuBpJj1kcVJviVsYnWpmT2uxY6iGqcQKJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
