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 reasonableload
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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
