[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Object Databases for Symbolics
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
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
Anyone have any experience with these issues? These products? Any
advice? Many thanks.
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
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
That's about all I can think of. Feel free to ask me more questions.