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

[Roland Mas]

Arnar Birgisson (2002-11-15 08:27:41 +0000) :

> I'm not a long time sf user but having worked on similar projects
> with regards to the plugin structure I have only one comment about
> point 5.

All comments are welcome :-)

> If possible, the plugins should not have to modify any pages not
> their own, or any files for that matter.

  That's the spirit, yes.

> Instead you could f.x. define insertion points for plugins, such as
> the "Public Areas", "Main menu", "Project config pages" (for a
> checkbox indicating if the group uses this plugin), "User page"
> (possibly subdivided) and plugins register themselves to be
> considered for certain insertion points. When rendering these areas,
> sf then selects all plugins that have registered themseleves for the
> area in question and checks for each one if the user/group uses
> it. That way, no modification to any files is neccary for each
> plugin, they only need to register themselves in the database.

  Interesting idea.  I'm not sure it would work, though.  I'll assume
we're speaking about just adding links to plugins in the webpages.  It
is true that for some plugins there will be no parameters to the link
apart from the group_id or user_id.  But for others, I expect they'll
need some extra parameters.  For instance, if someone hacks up a
plugin to draw Gantt diagrams, the links to it might be not on a
per-project basis but on a per-task or per-subproject basis.  So the
links might not be fully computable without further knowledge of the
plugin, which means patching the core files.

> There was a posting earlier by Tim suggesting the use of a
> register_plugin function.  I support this, that way with the
> addition of what I said above, the sf core system can have full
> control over the modifications of a plugin (providing plugin writers
> stick to protocol), and could even perform the creation of tables
> and other db objects for the plugin.

  The register_plugin function will of course be provided, if only to
keep track of installed plugins.  But just that function doesn't
automatically allow for full control.  Unless we go for a system that
patches the files at installation time, which I believe is ugly.

> That way there's even a possibility of the core system to keep track
> of neccessary data to uninstall a plugin, so lazy plugin writers
> that can't be bothered with writing uninstall procedures wouldn't
> have to.

  I'm not sure we want lazy plugin writers in the first place :-)
Seriously, though, keeping track of data inserted by external stuff
like plugins, like tables/sequences/views/etc, is a very hard thing to
do.  Either you have to monitor the actions of the plugin whenever
they occur, and that's going to be hard to do reliably, or you have to
establish a protocol through which the plugin requests the changes
that are to be made, and that's limiting the flexibility of what the
plugin can do.

> I really like the plugin idea and even though I have to agree with
> you on the calendar argument, it would certanly be useful in my
> companys application of sf. Keep up the good work.

  Well, get in touch with Kikov, you might be able to help each other
in implementing his calendar :-)

  Thanks for the feedback,

Roland.
-- 
Roland Mas

A lesson for you all: never fall in love during a total eclipse.
  -- Senex, in A Funny Thing Happened on the Way to the Forum