[tahoe-dev] plugin architecture for tahoe?
Brian Warner
warner at lothar.com
Mon Sep 6 18:34:48 UTC 2010
So, I've been wondering if we should build some sort of plug-in
mechanism into Tahoe to make it easier to ship non-core features without
adding to the dependency load of the core system.
I think the webapi is a pretty core feature, and basic HTTP comes with
Twisted for free. Having a "welcome page" and node-admin/status pages
are pretty core too. I'd like to change the way we render our admin
pages to stop using Nevow (and remove it as a dependency), which would
leave the WUI in as a core feature without much overhead.
SFTP, moved out to a plugin, would remove PyCrypto and pyasn1 from the
main dependency list. This would also move the "manhole" debug port out
of the core, since it also depends upon conch (ssh).
The JS-based download-status visualization would be nice to have in
core, but I think it could live in a plugin too. This plugin would add a
couple of static files (protovis.js, jqueryjs) and would add some links
to the existing download-status page (to point to the
timeline-generating JS).
The plugin interface would need the following sorts of hooks:
- claim portions of the URL space, like /status
- add links to existing pages, like /status/download-N
- access to the NodeMaker, to create FileNodes and thus upload/download
files
- access to a node-basedir temp directory, for SFTP files
- maybe access to the Tub, to make new Foolscap connections
and some others.
I'm not sure how I'd go about building the plugins.. there are a couple
of different approaches available (Twisted has one scheme, setuptools
and entrypoints offer another, Trac looks for .eggs in a well-known
plugins/ directory, mercurial has a config file which tells it about
modules to try to import).
thoughts?
-Brian
More information about the tahoe-dev
mailing list