<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
I think, in particular with respect to the oid issue, it is worth reposting <BR>
the note that I have added to the project as "BEN-RETIRING-TODO.txt".<BR>
<BR>
Some of the things he lists have actually been done (whoopy!)<BR>
<BR>
<BR>
Hi all,<BR>
<BR>
Thanks for your continued interest in Elephant.  Unfortunately I have<BR>
some bad news.  My day job has become all-consuming (and it<BR>
unfortunately does not involve working with Elephant at all.)  As such<BR>
I feel I need to step down as maintainer.  Andrew has volunteered to<BR>
maintain this project, but he will also probably have limited cycles<BR>
to contribute coding too.<BR>
<BR>
While it seems Elephant is in a semi-useful state, it does need more<BR>
work.  So, if you like Elephant and would like to make it better,<BR>
there are plenty of things to work on!  I will stay on these email<BR>
lists and try to contribute what knowledge I have.  Andrew will try to<BR>
coordinate.  I've outlined here various projects in priority order, as<BR>
I see them.<BR>
<BR>
At some point in the future I hope to come back!<BR>
<BR>
High-priority projects:<BR>
<BR>
1) we are storing persistent objects incorrectly.  they should be<BR>
stored only as OIDs, and we should have a separate OID->class table.<BR>
this way change-class can be handled correctly.<BR>
<BR>
2) GC.  Gabor has started on this -- thank you!<BR>
<BR>
3) New release.  Update docs, webpage to reflect new stuff.<BR>
(Sleepycat 4.3, SBCL+unicode, new MOP stuff.)<BR>
<BR>
4) Metering and understanding locking issues.  Large transactions seem<BR>
to use a lot of locks.  In general understanding how to use Sleepycat<BR>
efficiently seems like a good thing.<BR>
<BR>
5) Tests tests tests!<BR>
<BR>
6) LispWorks, Allegro 7.0 and OpenMCL compatibility.  There are some<BR>
patches which have been sent in (check the logs.)  Also someone sent<BR>
in Solaris patches a while ago.<BR>
<BR>
Difficult, but important projects:<BR>
<BR>
7) callbacks for btree sorting: right now the sorted btree sorting<BR>
function is a bit of nasty C code.  i have code somewhere which did<BR>
callbacks instead, i can try to revive that.  the issue is that the<BR>
sorter needs to know the underlying lisp representation.  this is a<BR>
screw for unicode strings and bignums.  the C code is a hack for 16<BR>
bit unicode strings for allegro / lispworks (using IBMs ICU stuff),<BR>
and for the sbcl unicode stuff (using glibc wchar stuff.)  also bignum<BR>
sorting is by approximation via floats, which fails after some point.<BR>
but in hindsight maintaining all this is probably a lose.<BR>
<BR>
8) Other backends.  Sleepycat is nice but has license issues.<BR>
Calling to C is nice but not nice.  Elephant is fairly modular:<BR>
serializer + MOP stuff + backend.  Therefore: write different<BR>
backends.  Possibly: Embedded Firebird, SQLLite (seems to not be that<BR>
great.)  Or, write an All-Lisp backend.  Copy what ZODB does (maybe<BR>
DirectoryStorage instead of FileStorage.)  Ask me for details.  With<BR>
SQL backends, there are possibility of using SQL types to solve some<BR>
of the btree sorting problems (and break others!)<BR>
<BR>
9) init/reinit object protocol: Dan Knapp suggests (or I infer) an<BR>
initialization / reinitialization protocol might be nice, since there<BR>
is a difference between objects which are freshly created and those<BR>
which are loaded from the DB.<BR>
<BR>
Med-priority projects:<BR>
<BR>
10) equality joins have to be done on the lisp side, since many lisp<BR>
btrees share the same sleepycat btree.<BR>
<BR>
11) single-user-mode: SUM = cache all slot values.  used to be high<BR>
priority, but i no longer want it, so unless someone wants it...<BR>
<BR>
Low-priority projects:<BR>
<BR>
12) class / slot to ID performance hack.  create a table which<BR>
contains slot definitions, probably cache this in memory on the class.<BR>
store slots as OID + slot ID -- avoid the symbol lookup.<BR>
<BR>
13) typed arrays.  some lisps can pass things like arrays of 32 bit<BR>
signed integers directly to C.  right now we destructure and<BR>
restructure.  invalidated by 11).<BR>
<BR>
14) bignum fixes.  OpenMCL: check that ldb is non-consing (i think it<BR>
is), look at %ldb-fixnum-from-bignum.  profile %bignum-ref on CMUCL /<BR>
SBCL.  or, figure out a great way to serialize bignums!<BR>
<BR>
15) peter b's patch to non-persistent objs.  check the list.<BR>
<BR>
16) dynamic-extent for transactions on SBCL/CMUCL.  i've tried to get<BR>
with-transaction to not cons.....<BR>
<BR>
Impossible projects:<BR>
<BR>
17) Serialize lambdas, closures, functions.  Seems to require<BR>
implementation support.  Also serialization of packages.<BR>
<BR>
Take care, B<BR>
<BR>
Seems to require<BR>
implementation support.  Also serialization of packages.<BR>
<BR>
Take care, B<BR>
<BR>
[read@localhost elephant]$<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
On Tue, 2006-01-24 at 12:13 -0500, Zach Beane wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">On Tue, Jan 24, 2006 at 11:43:16AM -0500, Ian Eslick wrote:</FONT>

<FONT COLOR="#000000">> That reminds me.  Without GC and/or renaming oids we'll eventually run </FONT>
<FONT COLOR="#000000">> out of OID address space, again when the DB gets enough use.  I haven't </FONT>
<FONT COLOR="#000000">> seen any provisions for fixnum wrap-around.  Am I missing something or </FONT>
<FONT COLOR="#000000">> is this correct?</FONT>

<FONT COLOR="#000000">This isn't a direct comment, but I recently came across this book:</FONT>

<FONT COLOR="#000000">   <A HREF="http://www.amazon.com/gp/product/0136298338/102-6097685-4704118">http://www.amazon.com/gp/product/0136298338/102-6097685-4704118</A></FONT>

<FONT COLOR="#000000">It has a concise but interesting chapter on the design and</FONT>
<FONT COLOR="#000000">implementation of the Statice database. You can also find it on</FONT>
<FONT COLOR="#000000">Abebooks for $1.</FONT>

<FONT COLOR="#000000">I don't have it in front of me, but IIRC it described Statice OIDs as</FONT>
<FONT COLOR="#000000">96 bit and intended to be unique across space and time. It also said</FONT>
<FONT COLOR="#000000">that the database was *never* garbage collected.</FONT>

<FONT COLOR="#000000">Zach</FONT>

<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">elephant-devel site list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:elephant-devel@common-lisp.net">elephant-devel@common-lisp.net</A></FONT>
<FONT COLOR="#000000"><A HREF="http://common-lisp.net/mailman/listinfo/elephant-devel">http://common-lisp.net/mailman/listinfo/elephant-devel</A></FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>