[elephant-devel] Inviting comment on future plans

[Ian Eslick]

Pierre,

> - confidence that there can't be data loss when using it,

I believe the current Elephant guarantees no data loss, or I would  
not recommend a 1.0 release.  I trust it in my own work, at least.   
You can, of course, shoot yourself in the foot by calling the wrong  
command and telling it to delete data.  And with BDB, at least, you  
can even recover from shooting yourself in the foot by recovering the  
database to a prior point in time.

Now, few pieces of software are perfect, but Elephant inherits the  
durability and recoverability guarantees (after writes commit) of the  
underlying database.  If you properly use transactions, the DB will  
never get into an inconsistent state.  I've used it on enormous,  
complex databases for months without any incident and several other  
people have reported similar success.  What we've been fixing is  
corner cases, adding small features and making it work robustly with  
a number of major lisp platforms.

To me (and Robert) a major release like 1.0 is defined by a coherent  
and well polished set of features, broad support for various  
platforms, excellent test coverage, some good real-world testing and  
complete documentation.    I think the current plan gets us there.

The portability layer porting you suggest are good steps towards a  
cleaner code base, better separation of concerns, easier code  
maintenance and evolution as well as simplifying future porting to  
other platforms.  However none of them change the user experience or  
significantly enhance the current operational stability of the  
project.  I'd be willing to look at this happening on a separate  
branch post-1.0, but I think it would be a distraction at this point  
since:

1) We don't really need thread portability (other than locks for  
which portability is a trivial 3 line addition per lisp),
2) UFFI is stable and is maintained when bugs or incompatibilities  
are identified (last patch was Oct '06). Updates are rare since it  
has a static, well-tested feature set and lisps don't change their  
FFI interfaces that often so there is little need for active support,  
and
3) We've duplicated and verified the corner cases in our use of the  
MOP, not all of which are fixed by Closer BTW, and closer only  
supports one lisp that we don't (CLisp).  I actually did a trial port  
earlier and judged that the headache wasn't worth the resultant  
benefits.

However the CFFI and threads port would make sense if we committed to  
supporting several new platforms.  (CLisp would be trivial to add if  
someone requests it, especially since it doesn't support threads last  
time I checked).

> - two or three big systems deployed for some months with some  
> reasonable
>   load

I do agree with this.  We've had two apps developed by Robert and I  
stressing the 0.5.0 and 0.6.0 releases.  If we had a handful of users  
who signed up to give Elephant a real stress test pre-1.0, I'd be  
happy to sit on a 1.0 release candidate for a few months while it was  
getting a good going over and doing any new development on a separate  
branch.  I can certainly volunteer as all my recent hacking on  
Elephant is preparation for a significant development project of my  
own that will stress Elephant considerably, especially the new features.

I respect your position on what makes a 1.0 release, but I think it's  
better to get the current product neatly packaged up and available  
before we go optimizing it further, especially since we don't have  
users clamoring for other platforms or features at this time.

I think the best thing anyone can do to get us ready for a 1.0  
release is to review and augment the regression tests to cover corner  
cases we haven't captured yet.  Is there a better way to test all our  
combinations of Lisp/OS/machine/word-size?

Cheers,
Ian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20070403/5a8ccd84/attachment.sig>