Poor mans plugins

[Stuart Rackham]

Being able to exchange bits of web2py functionality
painlessly is a nice idea. Robin and Massimo discussed
plugins in
http://groups.google.com/group/web2py/browse_thread/thread/17aab5d05511ff4a

Writing an AJAX demo got me thinking again about plugins --
here are some notes outlining a hypothetical plugin
infrastructure based firmly on the KISS principle.

I just love the simplicity of web2py's app tarballs, this
proposal extends this idea to packagable units of
functionality -- libraries/plugins/addons, call them what
you will -- I've chosen to call them contributions or
contribs (after the the web2py 'contrib' directory name).

I'll use the partials demo I wrote as a use case: To use
AJAX partials you need to add four files to your
application:

models/partials.py
static/jquery.form.js
static/partials.js
views/partials.html
contrib/partials/

Just put them in a tar file which can then be extracted
(installed) into any application. The fifth item is the
'contrib directory' where a MANIFEST file is written and
where optional files such as ABOUT and LICENSE would go.

To manage all this use the (hypothetical) 'contrib' script
which implements three commands: install, remove and make:

contrib.py [--force] install APPNAME TARFILE
contrib.py remove APPNAME CONTRIB
contrib.py [--file TARFILE ] make APPNAME CONTRIB

'install' extracts and writes manifest.
'remove' deletes installed files.
'make' creates a contrib tarball.
'CONTRIB' is the contrib name (omit to apply to application).

This scheme is simple and it fits into the current way of
doing things:

- There are no mandatory configuration requirements apart
from the contrib directory.

- There is no mandatory dependency management or versioning.

- Contributions are installed at the application level -- if
you want them in multiple apps you install them in each
app. Site wide libraries/plugins are good in theory but
not so good in practice, you know the drill, you upgrade
or modify a global library because you need a new feature
for your latest app only to find (usually much later) that
it breaks an existing production application (see
http://blog.ianbicking.org/site-packages-considered-harmful.html).

- Download and install contribs and apps from web (specify
URL instead of file name).

- For all those inevitable weird and wonderful things that
this simple scheme doesn't cater for you can include an
optional __contrib__.py script which can implement any of
the following functions: preinstall (return False to
cancel), postinstall, preremove (return False to cancel),
postremove, version. These functions would be executed in
a web2py execution environment. The version function
returns the contrib version number. All this stuff would
be optional though.

Good, bad or ugly?

I haven't filled in all the gaps, the notes I extracted this
from are really rough. I'll write a proof of concept
'contrib' script if there's enough interest.

Cheers, Stuart

[Kyle Smith]

I like this a lot. I prefer one copy per system over one copy per app, but this at least makes it easier to install and maintain plugins/contributions on a per application basis, and could lead to wide spread use of particular plugins. For example, the authentication and authorization mechanisms (has_role?) in KPAX could become a contribution/plugin. Then development could proceed as needed on just the contribution and it could expand significantly (has_group, from_ip, between_times) while having no impact on web2py core/gluon.

Kyle

[Massimo Di Pierro]

This is very similar to, but cleaner than, the model I used in KPAX,
so +1.

I assume a partial may generate an entire page or a portion of a
page. In the latter case this can be done via ajax or via explicit
function call. In the latter case we the partial may require a new
request or act on the original request (same for response). This
needs to be thought a little bit more.

Massimo

[Massimo Di Pierro]

I agree. There has to be a way to also store a version number of perhaps a uuid to each contrib module.

Massimo