Charm derivation

[James Westby]

On Mon, 16 Jan 2012 19:02:24 -0200, Gustavo Niemeyer <gustavo.niemeyer at canonical.com> wrote:
> I'm pretty sure many interfaces won't be relevant for a django charm.
> 
> I don't think all interfaces will be interesting for a django charm.

"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.

> >  * It would be a nightmare to maintain in lp:charms as you would have
> >    to agree to every addition that someone wants and keep all of them
> >    in mind when making changes.
> >  * Add in changing interfaces and you amplify each of these issues.
> 
> 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.

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?

> > To take a step back, what I want to be able to say is:
> >
> >  * I have a django app
> >  * It also makes use of these interfaces, which I wish to be provided
> >    by these particular charms.
> 
> Sure.. You want to create a charm specifically to a given django
> application, and that's totally reasonable as well. In this case, you
> can use Michael's charm merely as a guideline for your own charm and
> then deploy your charm as a full-fledged application with its own
> charm name and all. Great as well.

"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?

Thanks,

James