debian-sf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Debian-sf-devel] Plugin infrastructure -- Request for comments


From: Roland Mas
Subject: Re: [Debian-sf-devel] Plugin infrastructure -- Request for comments
Date: Fri, 15 Nov 2002 19:21:42 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu)

Justin Richer (2002-11-15 11:17:53 -0500) :

> I agree with this point. My suggestion would be to just have SF scan
> the table of available plugins and give projects the option of using
> them in addition to the built-in tools. It should mostly be a matter
> of querying the 'plugins' table and looping through the resulting
> rows in the correct places.

Could be done.  Except maybe we have plugins that are related to
projects, and others that are related to users, and others that are
related to foundries, and others that are related to one particular
subproject, and...  So the querying-and-looping is not completely
straightforward :-)

> We've done something similar, but less robust, with our sf-2.5-based
> project here. In general, I don't think it's a good idea to force
> plugins to modify existing pages, but in some places it will have to
> be done.

  Yep.  The "hook" idea is useful, and it's something I really like
(in Emacs, for instance).  I'll try to push it as far as I can, so as
to minimise the number of specific "insertion points" needed.

> You do run into the problem of plugins stepping on each other, then,
> though.

  Not if the insertion points are integrated into the main code and
managed centrally.  I do not believe there will be hundreds of plugins
requiring manual intervention anyway, so it should be manageable
without too much hassle.

> Especially if someone's running a more non-standard web-tree (as we
> are here).

  Well, you're on your own there, and you knew you'd be when you
decided to fork :-)  Seriously, depending how far you've drifted and
how you drifted, you might be able to maintain your own code as a
local modification to our public CVS tree.  CVS should be able to port
most of our patches to your copy, and you should only have to resolve
(hopefully rare) conflicts or particular points.

  Thanks for your feedback, I'll try to integrate it into the next
draft of my proposal, which I should post shortly.

Roland.
-- 
Roland Mas

Meaning lies as much / In the mind of the reader / As in the haiku
  -- in Gödel, Escher, Bach: an Eternal Golden Braid (Douglas Hofstadter)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]