Very cool indeed!

However, from a quick glance at your tutorial, it seems you could have folded this back into Boost.Serialization by writing a sqlite3 archive. Is there some reason you chose not to do this?

The main reason is the difference between "serialization" and "persistence". Boost.Serialization is not designed for "random access" to the data files. Consider a situation when you store several structs in one XML file. Serialization doesn't provide you any means to edit or at least extract only one specific element. All you can do is load the whole file, update some entries and write the whole set back to disc. You can build your own persistence solution on top of Boost.Serialization, but you have to do it yourself. And hiberlite is a persistene library - the main idea is to provide the smart pointers to objects inside the SQLite database. We really need some sort of SQL support in Serialization, but I don't see any good way to integrate features like primary keys, queries, tables metamodel, etc. So simply adding some sqlite output will look like a new file format, and that's not what RDBMS software is built for. But I agree, an idea of sqlite3_archive is very attractive, and also very challenging. http://code.google.com/p/hiberlite/ Yours sincerely, Pavlo Korzhyk ICQ#155870780