From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15248 invoked by alias); 15 Feb 2002 20:26:53 -0000 Mailing-List: contact sourcenav-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sourcenav-owner@sources.redhat.com Received: (qmail 15185 invoked from network); 15 Feb 2002 20:26:50 -0000 Received: from unknown (HELO shell4.bayarea.net) (209.128.82.1) by sources.redhat.com with SMTP; 15 Feb 2002 20:26:50 -0000 Received: from modrick (209-128-79-218.BAYAREA.NET [209.128.79.218]) by shell4.bayarea.net (8.9.3/8.9.3) with SMTP id MAA15859 for ; Fri, 15 Feb 2002 12:26:50 -0800 (envelope-from supermo@bayarea.net) Date: Mon, 18 Feb 2002 14:02:00 -0000 From: Mo DeJong To: sourcenav Subject: Re: Let's start it (Re: SN backend GPL or LGPL?) Message-Id: <20020215122544.7738e342.supermo@bayarea.net> In-Reply-To: References: Organization: House of Mirth X-Mailer: Sylpheed version 0.4.99cvs6 (GTK+ 1.2.7; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2002-q1/txt/msg00074.txt.bz2 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 > 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