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

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

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


From: Christian BAYLE
Subject: Re: [Fwd: Re: [Debian-sf-devel] The ongoing module conversation]
Date: Wed, 13 Feb 2002 14:36:17 +0100

Eric D Nielsen wrote:
> 
> Comments included below....
> >
> > 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.

> Excatly the modules are extensions to sourceforge.  One extension shouldn't
> interfere with another so if a sf-site operator wants to run some  of the
> modules, but not all it should be possible.  Migrating everything to the
> main database would be a nightmare.  First it increases the chance that two
> modules can't coesist (if they both want to add the same table, or add columns
> to the same originaly table, etc).  It also increases the unstability of the
> core SF.
> 
I was thinking at e.g. a property that is linked to the group table
like a per project pserver enabling. 

It's rather ineficient to create and maintain a new table for this.

A page accessing to 10 modules will access to 10 differents tables, that
can be 
very CPU consomming. 

There are in my mind separable functionnality and non separable ones.
It's sometime better to integrate. 

This is not in contradiction with the possibility of creating modules, 
that I would reserve for specifics stuffs.

> >
> > 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
> I don't think my modules, with a few exceptions, would ever be that univerally
> accepted.  The modules I'm working on, while adding siginificant, 
> functionality
> are small compared to the entire www directory.  I don't want to fork the
> www directory, that accomplishes nothing.  The goal is to have optional
> modules (expansion packs, if you will) that a sf-site operator can install
> if needed.  Furthermore the existence of an installed module should not cause
> problems during an upgrade of the "core" SF.  If the existence of a module
> causes a fork in the whole www directory, upgrades will not be easy.
> 
> Eric
We concluded, last time I discuused with Roland that a good way of
handling these
concepts is to try with what you did.
Do you have some fresh diffs for the last sf2.6-0+6?

Cheers


-- 
Christian Bayle



reply via email to

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