Object Databases for Symbolics

["RDP%ALAN.kahuna.decnet.lockheed.com"%ALAN.kahuna.DECNET.LOCKHEED.COM@Warbucks.AI.SRI.COM]

Received: from THOMAS.kahuna.decnet.lockheed.com by ALAN.kahuna.decnet.lockheed.com via CHAOS with CHAOS-MAIL id 21802; 8 Feb 90 14:23:46 PST
Date: Thu, 8 Feb 90 14:23 PST
From: Robert D. Pfeiffer <RDP@ALAN.kahuna.decnet.lockheed.com>
Subject: Object Databases for Symbolics
To: SLUG@ALAN.kahuna.decnet.lockheed.com
In-Reply-To: <19900207184752.7.PAN@Athena.Pangaro.Dialnet.Symbolics.Com>
Message-ID: <19900208222343.3.RDP@THOMAS.kahuna.decnet.lockheed.com>

    Date: Wed, 7 Feb 90 13:47 EST
    From: pan@Athena.Pangaro.Dialnet.Symbolics.Com (Paul Pangaro)

    We are evaluating how to proceed with a complex software application
    running on the Symbolics, which needs to be able to create and maintain
    large databases on the Symbolics, without worrying about "saving out" to
    maintain a permanent copy of things. The current application is heavily
    Flavor based, but with our home-brew tools is slow to "save out" and
    will probably chock on retrieval as the knowldgebase gets bigger.

    Portability is a later issue, but now we must get things going soonest.
    We can deliver for some time on Ivory products, but later want to move
    to other platforms. We want to stay object-based, of course, and dont
    want to port to "C" or anything else anytime soon.

    We are looking into a conversion to G-Base (from Graphael, whose
    products are now disctributed by Object Databases, Inc. in Cambridge)
    now; we know of course about Statice but have not seen it since its
    pre-release version.

    Anyone have any experience with these issues? These products? Any
    advice? Many thanks.

    Best,
    PANgaro

We're in a very similar situation here.  Unfortunately we haven't gotten
far enough to give you useful feedback about winning solutions.  I can
give you a brief outline of the path we've chosen if that's of any
value.

We currently have a "medium sized" (let's say 10,000 to 20,000 lines of
source code) Flavors based application in Alpha Test.

Supporting it with a real database is the highest priority.  We chose
Statice with the belief that it was the obvious choice (I've never
heard of G-Base before).  We have a "toy" Statice database the we would
just "drop into the application" except we've also taken the opportunity
to improve the design.

Part of the improvement is to convert from Flavors to CLOS.  This is
desirable for both new features (e.g. multi-methods) and long term
portability.  So we're working out the details of knitting Statice
DEFINE-ENTITY-TYPEs together with CLOS DEFMETHODs before doing a major
pass through the live application to convert it over.  If we were done
with this we could provide much more useful feedback to you.

The next step towards portability in this area looks like it will be
re-supporting BIN files (using DUMP-FORMS-TO-FILE) for users who are
willing to give up some features and performance.  We are initially
desupporting BIN files with the introduction of Statice so that we can
get this most additional functionality with the least software
development investment.

That's about all I can think of.  Feel free to ask me more questions.