Serendipity

From: Nick Leverton
To: blosxom-devel@lists.sourceforge.net
Subject: Re: [Blosxom-devel] Project status?
Date: Wed, 1 Aug 2007 18:03:49 +0100
Message-Id: <200708011803.53695.nick@leverton.org>
In-Reply-To: <20070801072437.GA19249@katherina.student.utwente.nl>

On Wednesday 01 August 2007 08:24, Matthijs Kooijman wrote:
> > This then gives a way to move Blosxom forward by taking the canonical
> > plugins as mainstream, so that the relevant features will work in the
> > same way for all plugin authors.
>
> Another thing that would be useful is to define some standards for how
> plugins should (roughly) do their work. In particular, it would be useful
> if plugins could define their own hooks, which yet other plugins could
> fill in. These hooks could be somewhat standardized (ie, all the
> different comment plugins calling a "spamfilter" hook that other plugins
> can use to implement blacklisting, or captcha's or stuff like that.

Certainly. In fact I've seen another plugin implementation, the one in
qpsmtpd, which has some neat ideas that I've thought about borrowing - many
of them are included in my lists below.

The following seem to me to be essential principles to help us get on top of
the plugins and base Blosxom functionality. I think they ought not to be
too disruptive to the existing code base. Some of them are things others
folk have mentioned here, which I hope I've represented fairly.

If we are going to get Blosxom more widely used, we will need both to make
packagers' jobs easier and also to make it simpler to configure a package
without editing static files, so I have tried to have regard for that as
well.

• As far as possible, any changes should be backwards compatible. If an
  incompatible change is unavoidable then consider introducing a new hook
  instead and deprecating the old one.
• All plugin hooks should work in the same fashion
• All plugin hooks should support being hooked by many plugins (and the
  plugins should cater for it too)
• The effect of having multiple plugins on one hook will be defined (and, so
  far as possible, will also be useful !)
• As far as possible, the order of plugins should not matter. Consider
  introducing new hooks where this would make logical sense.
• If ordering the plugin calls is unavaoidable, it will not require renaming
  files (though this can still be done, for backwards compatibility).
• So far as possible all dynamic information will be cached. There will be
  standard routines for accessing filestore through the cache.
• All plugin configuration will be supported via an external config file,
  without the need to edit the plugin code.
• Failure of or inside a plugin will not lead to failure of the entire
  weblog (this one has caught me so many times as I try out plugins !)

These are some thoughts about important but IMO less essential principles,
which might make it easier to implement some plugins or which address some
of the other concerns raised here:

• Plugins may choose whether to work on the semi-rendered output of the
  previous plugin, or on the un-rendered original. Default will be to
  continue on the previous output.
• Plugins may choose whether blosxom should continue processing a hook or
  whether the posting is now complete as far as this hook goes. Default will
  of course be to continue processing.
• It will be simple to define additional hooks for user requirements.
• Plugins wil lbe able to conditionally call hooks in other plugins (for
  interpolate_fancy etc).
• There will be a standard way for plugins to keep state. This will be
  cached and integrated with the dynamic information cache. It should also
  support non-cached BLOBS of some kind, for gallery plugins etc.

Any comments, additions, deletions please ?