Eyvind Ness asked if I would describe my experience with this stuff, in
particular Itasca vs other things.
history: in early 1988, I began working with GBB (Generic BlackBoard)
from UMass. a few months later I began using the distributed/multi-host
version. GBB is a blackboard tool, not a real database. it has
persistence of a sort, but not really like a database; every object
instance is held in RAM, and there are dump and restore functions. what
it does that's nice is it handles distributed object delivery and
function-call triggering of receiving processes. I used it on TI
Explorers.
it was great--we didn't need persistence, we needed the other
capabilities. we weren't using the actual BB-like aspects, although we
probably could have with a different design of our system.
so when time came to look at OODBs in 92, I wanted something that had
similar features to GBB.
spring 92: Health Care project. after some KE, we decide that we will
need an OODB. we know little or nothing about them. we gather some info,
and in August make a sweep of reading about them. we got a variety of
manuals and such like for a handful of them, and the MIT report about a
bunch of them, and the [Michigan?] report about some comparison testing
(and some legal fallout).
the top contender early on was ObjectStore, the only one we really knew
much about. after the MIT report, Itasca jumped to the front by being
rated better than all the rest almost across the board.
we did some phone calls, asked question, and decided to buy Itasca in
September 92. the primary reasons were: it was the oldest of them all,
there were lisp and C and C++ interfaces (important since our
"co-contractor" would be using C/C++), and had other good features like
a notification (funcalling) mechanism (which we didn't get to try out).
no regrets yet.
what it didn't have that we really needed was a true, complete,
client-server mechanism for connecting multiple clients. there was a
mechanism, but it was weird, because effectively the clients all ran in
the server, and could interfere with each other (name-conflicts,
especially with clim).
Itasca is a large lisp app with a chunk of C-code in there as foreign
functions. so it runs built into a lisp image. this is one of the
reasons we liked it. it's pretty fast in the lisp image, even on a Sparc
2. but all the objects are (effectively) defstructs, which means that
CLIM thinks they're all alike (defstruct-class). not good for us.
in Oct 92, with Gregor's help (thanks, pal!), I wrote a MOP CLOS
interface to Itasca. I sent them my code. Itasca itself came out with
a very similar interface in their subsequent release, and theirs was
better in several respects--I stopped development once it was working OK
for what we needed. didn't allow non-persistent slots.
In spring 93, Itasca came out with a remote-client interface mechanism
for lisp. we experimented with this a little bit. much better scheme,
with truly separated clients. there is still a little more than needs to
be done with this, but it's pretty good (esp in comparison with the
previous mechanism). unfortunately, their CLOS interface doesn't work
with the remote lisp; it only runs in the server lisp.
later the HC project died, we all moved on. I came to
BBN, and again we needed an OODB. Objectivity had already been bought,
but we were having massive problems with it. so we changed to Itasca,
largely because of my existing experience with it.
so we bought Itasca again. I have since modified my CLOS interface to
run with clients while connected to a server, it minimizes reloading of
objects (don't reload from the DB until you actually touch things,
because a reload of a bushy tree of connected objects could take a
noticeable length of time, mostly inter-process communication), does
allow non-persistent slots; a future improvement will allow
non-persistent mixins. the client-server mechanism has since been
improved, along with other speedups and such like.
we like it. Itasca is a big program, so of course it takes some tuning.
we haven't created more than a few dozen objects yet, and because the
classes continue to change, we tend to throw out old ones after days or
weeks. storage capacity is limited to the size of the disk partition you
initialize into, so that could be several gigabytes (and multimedia
items aren't stored in the DB, so you don't waster 100 MB for a movie in
the DB). I don't know if/how performance degrades as the DB fills up. I
only tried ~10 thousand obj instances.
AllegroStore from Franz: (no personal experience, just reading material)
uses ObjectStore. therefore it has Lisp and C interfaces. good. blazing
fast, I'd guess, since ObjStore is fast. (Itasca is OK, but not blazing.
I did some speed trials on the Sparc 2 in spring 93.)
a MOP-based CLOS interface. looks very similar to mine and Itasca's.
claims to have dynamic class/schema modification. (Itasca does too, and
much of their lisp interface is very clos-like, even using the same
names)
uses page-faulting and page-locking mechanisms. personally I find these
disquieting.
A-S can nest transactions. Itasca does not. I have the feeling it
would be good if we could do this...
A-S costs more than Itasca, from the info I have. (other OODBs cost
even more than A-S.) maximum cost for Itasca is ~$10K (if you're not
buying a lot of user-licenses). minimum for A-S seems to be ~$10K.
A-S looks convenient to work with. I need to add similar convenience to
my itasca stuff, but we don't really use it in a way that does a lot of
searches.
my use of Itasca has been one search to find all top-level instances,
let the user choose one by name, and then chase pointers down to other
things. this works great, and doesn't stress the DB at all.
anyone interested is welcome to a copy of the Itasca CLOS interface
source code. just email me.
-- clint
From: DANIEL CORKILL
Subject: Re: persistent object store for CLOS? (long)
Date:
Message-ID: <2t2h98$stu@opine.cs.umass.edu>
In article <··········@info-server.bbn.com> ·····@bbn.com writes:
>history: in early 1988, I began working with GBB (Generic BlackBoard)
>from UMass. a few months later I began using the distributed/multi-host
>version. GBB is a blackboard tool, not a real database. it has
>persistence of a sort, but not really like a database; every object
>instance is held in RAM, and there are dump and restore functions. what
>it does that's nice is it handles distributed object delivery and
>function-call triggering of receiving processes. I used it on TI
>Explorers.
>
>it was great--we didn't need persistence, we needed the other
>capabilities. we weren't using the actual BB-like aspects, although we
>probably could have with a different design of our system.
>
>so when time came to look at OODBs in 92, I wanted something that had
>similar features to GBB.
>
UMass GBB did not stop evolving in '88 (but it did go commercial), and a
substantial amount of development has gone into GBB since the UMass GBB
release you liked so well. The blackboard remains a main-memory
database, with save/restore facilities (and in NetGBB, send/receive
facilities), but when persistence is needed, GBB's blackboard units
(CLOS objects) can be married with a CLOS-compatible persistent object
store (such as AllegroStore). This approach is nicely suited to
situations where you want the advanced triggering and retrieval
facilities that GBB provides for all your blackboard objects and
persistence for some of them. (Making all blackboard objects persistent
is generally a bad idea for performance reasons.)
A percentage of GBB users do use it as a database of sorts, building
directly on GBB's blackboard database substrate (not including or using
GBB's knowledge source and control shell layers). It might be
worth another look....
-- Dan