[Debian-sf-devel] The ongoing module conversation

[Eric D Nielsen]

Thanks for getting back to me with your thoughts.

I'm glad your priority is a high quality, easily installed package.

Likewise I also agree that module shouldn't be exclusive, ie they shouldn't
conflict with each other, but this may not be possible in some cases. (Ie
there could be two different security modules that give different enchancements
that couldn't coexist (of course there would be no reason to have both.))

Yes I can get ride of the (meta-)modules database.  I was already using a per
module include file with the only thing in the modules db was whether a module
was active or not with the module include file sharing the name of the module
and installed in www/module/includes/module_name.inc

Currently my extensions query/update the sourceforge database through the
functions in database.php (ie like any other procedure).  If they need their
own storage space they create a seperate database.  Ideally some modules
would like to have their storage migrated to the core over time.  (Especially
the security stuff we're looking at, as it will be required on every page, ie
two db connections all the time.  Most module will only need the connection
when the user is using it so its an acceptable overhead.)

You're right that the patch system to locally apply hooks as needed isn't 
perfect, but I'm not sure if the proposed alternative is any better.  So
far none of the modules I've been working on are new project tools which is
waht Roland's hook system would work very well for.  I have three modules
under development right now:

Foundry-Grouping -- Allows the creation of for layout/display/navigation
                    purposes meta-foundries (ie you could have one for
                    tools(php,c,etc), one for departments, and one for
                    general guidlines.  Also allows hierarchial foundries,
                    and the easy addition/removal of foundries from groupings
                    and other foundries.  Hoping to add a tool to short-cut the
                    creation of foundries for the site admin, ie not have to
                    do the full project registration/review/change to foundry.
                    This is a tool used by the site admin only.  It would need
                    to have Roland style hooks added either to the site admin
                    home page, or at least add a single link from the site 
                    admin page to a module admin page and reach this module
                    from there.  (ie this is a easy hook)  It generates
                    a few .inc files that can be included in menus or elsewhere
                    as needed, how to add hooks to all the places in the code
                    to display this is harder.

License-Management -- Allows the addition subtraction of licenses from the
                   license list, allows the creation of different classes
                   of uses who have different license selection availibility
                   (For instance, all our government users must select
                   Public Domain, other users will be offered an OS license
                   that's been approved by their companies legal office
                   (we have a small number of outside companies allowed
                   access).  This module may or not be useful to the general
                   sf community.  However it needs a the admin hooks like
                   above (easy) and a hook on the project creation page 
                   (again easy, but begins to show all the possible places
                   that needs a hook)

Security -- this is both an infrastructure module and and project admin tool.
         The goal is to allow projects admin to partition their project
         and cvs space into areas accessible by sub groups of their project
         (some of what savannah already does) and also extend the "levels"
         of authentication required for differen components.  So there
         would need to be a hook for the project admin (again this is easy
         with Rolands suggestion), but now every page needs to check if
         the given user has access to teh requested tool( again a single
         hook in either logger.php or session.php or pre.php can accomplish
         this, but again how do we plan for all the hooks needed?

Another planned module:

Branding -- a web module for use by the site admin to customize their site
         would allow the replacement of SourceForge with their name,
         change the appropriate VA Linxus/Software to their company(leaving
         the copyright ones alone, etc), the modifications of the theme,
         selection of graphics, etc.  Some of these changes are in the
         Base_Lanaguage file, others are changes to headers/ footer/ menus/
         themes, all over the place.... how would we add all the hooks 
         needed for this?

Or are you proposing that as hooks are needed they are submitted for inclusion
within the source and not considered upfront?

I hope the above discussion gives you some since of what I'm considering.

Eric