<!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>
IMHO:<BR>
<BR>
I am using Elephant happily now, and want to go live with a system that uses it, but can't abide<BR>
by the Berkeley-DB licensing restrictions.<BR>
<BR>
After 48 hours considering the problem, you are correct---it will require some major rewriting, at least<BR>
to be elegant. I can remain code-back-compatible, but the class structure of the controller has<BR>
to be significantly extended.<BR>
<BR>
As to CL-SQL, it is a fabulous system; in fact, Elephant can sit on-top of CL-SQL and thus,<BR>
more or less easily use the 5 or 6 backend databases that CL-SQL supports easily. My goal<BR>
would be to seamless support that, as well as the Berekely-db, so that one can simultaneously<BR>
use different systems. One of the beauties of such as system is that one can migrate from<BR>
one DB implementation to another almost trivially if one can simultaneously read LISP objects<BR>
out of Sleepycat and put them into Postgres, for example.<BR>
<BR>
CL-SQL also, as you point out, provides a relatively easy way of getting CLOS objects into<BR>
a database, by allowing one to easily specify a mapping onto SQL-data types for each slot.<BR>
This is similar to Hibernate in the Java world. Although this is valuable for some applications,<BR>
I think the Elephant persistent object approach is even more valuable. For the work I've been doing<BR>
for the last 8 months, it is wonderful to be able to change a class and have it just work with<BR>
Elephant, and not even have that small additional step that CL-SQL requires of mapping things<BR>
into SQL data types. This savings in labor is relatively small, but worth fighting for!<BR>
<BR>
Although I might chicken-out, my current plan is to continue rewriting Elephant so that it <BR>
can use both Berkeley-DB and CL-SQL. I will then be morally compelled to release this<BR>
under the GPL, since Elephant is under the GPL, even if not legally compelled to do so <BR>
since I am not redistributing the code to anyone. I would rather get some kind of opinion or <BR>
approval from the existing Elephant owners, if they agree it is worthwhile, than to release it <BR>
as a fork. It will require some approval because it will be a pretty major rewrite; not just<BR>
a patch or extension.<BR>
<BR>
As to owning Elephant, it seems sensible that I could do it if I manage to complete this non-trivial<BR>
programming project satisfactorily. However, I am not yet a masterful LISP programmer, and <BR>
moreover have never owned a public software project and have no idea what that entails. If <BR>
one of y'all can describe the responsibility to me accurately, then I might consider it.<BR>
<BR>
Finally, do we have any idea how many people are using Elephant? If I do this work, will<BR>
I be the only person using it? If it's not going to help very many people, I could just do <BR>
the extra work to construct the CL-SQL mappings and save myself a lot of time.<BR>
<BR>
<BR>
On Thu, 2005-09-15 at 18:49 +0900, Ben wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">we (the elephant owners) have been silent for far too long, sorry. to</FONT>
<FONT COLOR="#000000">make a long story short -- neither of us have time to own elephant</FONT>
<FONT COLOR="#000000">anymore. we've been debating on the side about how to deal with the</FONT>
<FONT COLOR="#000000">lack of time, and have procrastinated more and more....</FONT>
<FONT COLOR="#000000">so we're looking for a new owner for elephant. we'll be happy to</FONT>
<FONT COLOR="#000000">answer what questions we can, but i don't forsee having the time to</FONT>
<FONT COLOR="#000000">deal with this for at least a year (or whenever my dissertation is</FONT>
<FONT COLOR="#000000">done.) i'm really sorry to leave you folks hanging.</FONT>
<FONT COLOR="#000000">the good news is i think it shouldn't be too hard to deal with the</FONT>
<FONT COLOR="#000000">code base, which as you can see is not too big. the code is also</FONT>
<FONT COLOR="#000000">fairly modular: there's some CLOS magic to make persistent objects, a</FONT>
<FONT COLOR="#000000">lisp datatype to byte stream serializer, and then the berkeley db back</FONT>
<FONT COLOR="#000000">end. plus a bit more here and there.</FONT>
<FONT COLOR="#000000">to answer the immediate question, i don't think there's any reason why</FONT>
<FONT COLOR="#000000">one couldn't write a postgresql back end, but it might require some</FONT>
<FONT COLOR="#000000">thinking about redesign. elephant assumes that the underlying</FONT>
<FONT COLOR="#000000">database is byte-oriented. i assume this is possible with postgresql</FONT>
<FONT COLOR="#000000">but it doesn't really make much sense to use an SQL database without</FONT>
<FONT COLOR="#000000">using the SQL types. that's just my opinion though. if one wanted to</FONT>
<FONT COLOR="#000000">use SQL data types then maybe one should try out CL-SQL or somesuch? </FONT>
<FONT COLOR="#000000">i dunno. i think there are other possibilities for a back end. </FONT>
<FONT COLOR="#000000">someone on the list a while back was talking about writing a lisp back</FONT>
<FONT COLOR="#000000">end. that would be interesting. i think sqllite might also be a</FONT>
<FONT COLOR="#000000">possibility.</FONT>
<FONT COLOR="#000000">there's a few patches hanging around in my mail folders (probably on</FONT>
<FONT COLOR="#000000">the list archive) which should be applied. the CVS elephant is close</FONT>
<FONT COLOR="#000000">to a release, it just needs some tagging and regression testing.</FONT>
<FONT COLOR="#000000">sorry i'm writing from korea and i'm rather jetlagged. but i'll be</FONT>
<FONT COLOR="#000000">back in the states soon.</FONT>
<FONT COLOR="#000000">any takers? </FONT>
<FONT COLOR="#000000">Ben</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>