[PATCH] Add support for external command handlers

[Rusty Russell]

On Sat, 2005-05-07 at 19:16 +1000, Aaron Bentley wrote:
> I should note though, that what I was doing with Fai was treating Tom
> Lord as 'damage' wrt usability, and routing around him.  With Martin, I
> don't think that's necessary, so Python scripts might be best, as they
> allow him to integrate them into the core as appropriate.

Hi Aaron!

	I think you missed my point with this change.  There are several
reasons for external commands:

1) it allows you to customize bzr for your own weirdness,
2) it allows you to fill temporary holes in bzr functionality generally,
3) it provides a simple entry point into bzr development,
4) it allows Martin to see what is missing in bzr, and
5) it allows Martin to push off niche features into "contrib".

(2) is most pressing for me now: I can implement "bzr push" *for my
project* in a one-line shell script ("rsync....").  Implementing that in
python is just silly, and of no use to Martin.  Similar arguments apply
to (1): they have to be rewritten anyway to be general, so the initial
language is unimportant.

(3) is also important for the vitality of the project, but in the short
term it's better for Martin to be writing the missing infrastructure
than arguing over minor patches.  (4) and (5) will become important
further down the track, a-la netfilter's patch-o-matic.

Now, I think a python extension facility is a good idea, any maybe this
will suffice, but forcing extensions to be in Python undermines the
effect of this now.

Hope that clarifies why I think this is so important,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman