[Fwd: Re: [Debian-sf-devel] The ongoing module conversation]

[Christian BAYLE]

-------- Original Message --------
Subject: Re: [Debian-sf-devel] The ongoing module conversation
Date: Tue, 12 Feb 2002 01:04:30 +0100
From: Christian BAYLE <address@hidden>
Reply-To: address@hidden
To: Eric D Nielsen <address@hidden>
References: <address@hidden>

Eric D Nielsen wrote:
> 
> 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

I would say that in this case, you are proposing extension, that are
option but
AFAI understand not mandatory.
I think, it's the kind of thing we can integrate.
It's probably better to add what you need in the database, because if
every module
has its own database, It can start to be rather tricky to manage.

I would say that a nice way to to this could be like this:
        Taking in account that we will soon split the package.
        (Next step, after we are sure that upgrade goes smoothly)
        Then there could be a web module containing only the web part, that 
        you can replace with your patched version. 
        "sourceforge-web-ericnilsen" provides sourceforge-web
        
        You would have to provide a script to create/drop the extra tables you
need
        that e.g. could be
        "sourceforge-db-ericnilsen" required by sourceforge-web-ericnilsen 
        
        (maybe not, because, some admins will maybe want to put the db on one
box
        the web on an other one.)

And if everybody is satisfied, this will replace the originale
sourceforge-web

Cheers, 
and thank you for your contribution, past and future :-)

-- 
Christian Bayle