Am 04.03.2013 16:52, schrieb Jarrad Waterloo:

So if your library is in need, which it is, than release it, preferably to boost under the boost license. You can always improve, add on latter. You may solicit architecture and requirements from the list to increase its usefulness and minimize rewrites. If you can't provide enough manpower to complete it or even if you can, than solicit help. If four people throughout the world can get it done in half the time of one person than WOO HOO! There are many who would like to contribute from the beginning, which also can't hurt acceptance. The important thing is to have a vision, preferably shared, and to release something usable, useful and working, as quickly as possible before interest dries up and in a timely manner.

Thanks for your remarks! Specifically for Persistent:

Have you considered an MVCC [option] where there are no updates from a users perspective but are rather inserts; This sacrifices hard drive space for a lock free/low lock database.

yes, the entire storage backend is based on MVCC [1]. there currently is no lock-based option. objects are MVCC in memory for concurrency (see section "concurrent transactions" [2]), and on disk to achieve atomic updates. when an update is safely synced to disk the old object versions are discarded. I haven't written much about the backend in the documentation for two reasons: the interface is most important, and I actually don't think it would get used much in the long term. as much as I try to make it safe and efficient, a backend using an industrially proven storage engine like BerkeleyDB or SQLite would almost always be preferred, if the stored data has any value. I've written more about this in a previous reply to Klaim-Joël Lamotte in this thread. Would you like to share anything on the architecture of the interface?

Since you in some ways may be competing against relational databases by making a object oriented database, maybe equivalent administrative functionality are in order such as import and export into some textual representations. On a related note, ways to access system information such external id/OIDS, timestamps, version numbers via an API for tooling and maybe querying purposes ?File format specifications?

this and much more is certainly needed for database applications. but since we don't have the resources to implement an industrial-strength storage engine, my approach was to provide one "black-box" implementation for applications that would have used (boost.)serialization or other files otherwise, and provide resource managers using external databases later on.

Concerning my interest, why haven't you given this to me two years ago, how much longer must I wait. [Ha Ha Ha]

*pointing to the copyright notice* :p Regards, Stefan [1] http://en.wikipedia.org/wiki/Multiversion_concurrency_control [2] https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/...