Re: [Debian-sf-devel] 2.6-0+6 available

[Roland Mas]

Eric D Nielsen (2002-02-07 13:05:39 -0500) :

> I couldn't tell if you have a solution for the extending database
> issue, or were looknig for one....

We have no solution as of yet, only ideas.

> I've almost finished a working prototype "module" system to solve
> the extending the database problem.

  That's cool.

> Ie each module has its its own sub-directory in www/module/ where it
> lives the module have their own postgres database, if they need to
> store data not already in the sourceforge database.  There is one
> "module" level additional databases that tracks which modules have
> been installed for administration purposes.

  Okay.  Having a enire database just to keep track of the list of
installed modules sounds a bit overkill, though.  Would a simple
modules.inc not be enough?

> Modules can also have patch file associated with them that is used
> to hold the additional "hooks/redirects" to add the necassarily
> links from existing pages to the module.
>
> I've taken the above patch approach, because the number of hooks
> that would be needed is so large that is isn't worth it at this time
> to go though the base code and add all them in.

  Hm.  I'm not sure I agree.  Patching the files will introduce many
problems related to evolutions.  What if the patched file has changed?
What if the patch doesn't apply properly?  What if the patch conflicts
with another patch for another module?

  Besides, the number of hooks needed shouldn't be larger than the
number of patches, so I don't think the second paragraph holds much
water.  I'd much rather have the hooks in a form like

,----
| if $GLOBALS['installed_modules']['<yourmod>'] {
|    print '<a href="/<yourmod>/index.php">Thingy tracker</a>' ;
| }
`----

  This could of course appear first as a patches, then be merged into
the mainstream code.  That would be easy to arrange: it's just a
question of synchronisation, you remove the hook from your patch at
the same time as I add it in the main code, and we fiddle with
versioned dependencies/conflicts to ensure the packages are upgraded
at the same time.

  I think this would allow a better model: drop the files in the
appropriate directory (including a module config file in the
appropriate /etc/sourceforge/modules/<yourmod>.conf), run
sourceforge-config, and voilà.  Want to disable it?  Edit the config
file, sourceforge-config, and you're done: the files are still there,
but they're disabled.

> If this approach sounds good, it would be useful if the upgrade
> doesn't touch/ destroy the www/module directory and (optionally)
> reran the patches found in that directory to reapply the hooks....

  That's one of my main concerns.  The www/modules/ dir I'm okay with,
but the patch thingy will rapidly become unmanageable.  Especially
since we would like to have parallel development of modules and the
main code, which means the main code will be changed from time to time
to fix bugs, which means the patches might not apply cleanly anymore.

  Don't misunderstand me: I *love* the concept of independently
developed plug-ins/modules/extensions/whatever, it's just the patch
thing I'm not too enthusiastic with.  And I must confess I'm a great
fan of hooks and blah.d/ directories (must be my Emacs addiction ;-).

Roland.
-- 
Roland Mas

Au royaume des aveugles, les borgnes n'ont qu'un oeil.