Charm derivation

[James Westby]

On Mon, 16 Jan 2012 18:15:37 -0200, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> > Writing a generic charm to handle all these cases would be a mistake,
> > but I want to re-use the logic for the django apache/mod_wsgi parts, as
> > they will be  It feels like this is the correct thing to do, as long as you add some framework-level API to query whether a given relation is established. very similar across the apps.
> 
> Why do you think it'd be a mistake?

Writing a single charm to handle django with any other interface that
may be provided by a charm?

I can see several problems with that:

  * It would be very unwieldly: hard to read and write
  * It would be very hard to test
  * It would have to support every conceivable interface, including
    non-public interfaces, for instance if I have two django apps that
    have to communicate through some specific interface I would
    immediately be unable to use this mega-charm.
  * The mapping from interface to settings.py attribute isn't
    standardised for the most part, you could make use of an AMQP
    interface expecting the credentials to be specified in any
    attributes that you want.
  * It would make that generic charm the framework, rather than juju.
  * I don't think it would be possible to make use of the charm twice in
    the same environemnt with different configuration (again the example
    of two django apps that have to communicate)
  * 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.
  * You would have to put all of this plumbing in place for each charm
    that targets a frameworks (django, zope, pyramid, ruby on rails,
    cake PHP, etc., etc.

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.

Most of that would be provided by stacks, remembering the specific
charms, and the config settings, but it still needs to know how to map
the interfaces to django settings.

For each interface the relation attributes are well defined, so all I
would need to specify is the attributes to map these to (perhaps with
defaults for e.g. db, which is standardised for standard uses in
django.) The rest could then be handled by generic code.

Yes, this can all be done in a single charm, but I don't think it should
be.

Thanks,

James