Re: Let's start it (Re: SN backend GPL or LGPL?)

[Mo DeJong <supermo@bayarea.net>]

On Fri, 15 Feb 2002 19:41:47 +0200
Eray Ozkural <erayo@cs.bilkent.edu.tr> wrote:

> IMHO, we don't need a license different from GPL. Let it remain free...

If we directly swipe SN code then it would have to be GPLed. If instead we
simply swipe the APIs and ideas then it could be licensed under a LGPL
or Berkeley style license.

> We still have to decide on a name. I suggested sourcebase, and Mo said fuzzyp
> (but that's a fuzzy name ;).

I think the name still needs work. Can anyone think of a good name that captures
the concept of a database of symbols and/or fuzzy parsing? I don't think the
name has to have anything to do with sourcenav since we would expect that
other projects want to use it too.

> It's probably going to be hosted on
> sources.redhat.com so we have to do an initial import to start the work. I
> suggest that we start with the source/snavigator directory, with all its
> contents (we don't build gui/ though). That way, we'll be forced to drop
> hacked versions of tcl/tk and the old db.

Well, the Tcl/Tk version on sources now is a rather stock 8.3. The old releases
were built on "hacked Tcl/Tk" versions but that is not really the case anymore.
I think we are fine depending on the Tcl version on sources for the Tcl API
to the database layer and the testing framework.

> It was said on this list before
> that the old berkeley db was used for performance, but is that really true?
> We can go for the latest berkeley db instead of that one. It might also allow
> us to use a few advanced features, those people are crazy for performance.

The newer releases of BDB have a feature that allows for atomic operations.
If something crashed the DB should not become corrupted. This seems like
an important new feature since a hosed symbol DB is one of the more common
problems in SN.

> With that directory, we're going to have to work on the build system and do
> some changes (hopefully minor) for a preliminary version. I tried the
> feasibility of that and it doesn't seem hard, I've got it half-working here.
> 
> We can keep the C and tcl/tk interfaces in, and simply disable all GUI stuff.

I think reworking the C API is the most important and most critical initial step.
Once you get into the guts of the existing C API, you realize that it appears to
be a rather clean layer on top on a more scary DB interface. I think we want
to just keep the clean layer and avoid the more scary bits.

Mo