public inbox for
 help / color / mirror / Atom feed
From: Mo DeJong <>
To: sourcenav <>
Subject: Re: Let's start it (Re: SN backend GPL or LGPL?)
Date: Mon, 18 Feb 2002 14:02:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 15 Feb 2002 19:41:47 +0200
Eray Ozkural <> 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
> 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.


  reply	other threads:[~2002-02-15 20:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-15  9:43 SN backend GPL or LGPL? (was: SourceNav release...) Doug Fraser
2002-02-15 12:26 ` Let's start it (Re: SN backend GPL or LGPL?) Eray Ozkural
2002-02-18 14:02   ` Mo DeJong [this message]
2002-02-20  1:59     ` Eray Ozkural

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).