Charm derivation

[Gustavo Niemeyer]

> "application" charms, probably not on the most part, but "plumbing"
> charms most could be used, and in this scheme if one person wants to use
> them then the generic charm would have to support it.

Indeed.

>> These sound like normal requirements for any relevant charm regardless?
>
> You mean any generic charm, or any charm at all? I don't think that the
> wordpress charm maintainer will have to deal with requests to add a
> hadoop interface.

What I meant is that I also expect the wordpress charm maintainer to
have changes cross-reviewed by other interested parties.

> Also, there are the interfaces provided by django applications. http is
> an obvious one, but it's possible to provide any interface, so the
> generic charm would have to support that as well, no?

Yes, that'd fall onto the dynamic interfaces question. Something to think about.

> "use [...] merely as a guideline" is what I want to avoid. People are
> going to all of this hard work to support all these web frameworks, and
> then those of us with slightly unusual requirements only get guidelines
> out of it?

That's a good point. If there's some very nice logic being developed
for a specific framework, there's no reason to be duplicating it
everywhere, and the way to do that is quite usual: get that logic in a
common location (branch, package, etc) and base charms on it.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.