Hello boosters, I am working on http://yade.wikia.com project and we plan to switch to boost::serialization. boost::python is already used (many thanks for that fantastic piece of code). Let me explain the current state first. We use custom serialization interface: each class registers various attributes of objects; at serialization, archive of pointers to the attributes associated with attribute names is created and serialized to XML (and vice versa for deserialization). Boost.python is used to wrap c++ objects in python. Each wrapper class defined __getattr__ and __setattr__; if called, the wrapper: 1. Checks that the underlying c++ object has an associated archive of attributes created. 2. Gets/sets the value of the attribute based on its registered name (because of current limitations, the value is passed to the archive as string) The advantage is that there is no need to wrap every single class in python, just a few top-level classes; and access to all other attributes of the derived types is automatically provided by the serialization framework. My questions are: 1. Do boost::serialization archives keep pointers to attributes, in such way that it is possible to keep one archive instance per object and use it to write an attribute continuously, with the change being immediately propagated to the c++ objects, and ask the archive for attribute value based on its name? 2. Is it possible (or has it even been done) to define python_iarchive and python_oarchive that would (de)serialize between python and c++ types (such as std::map to dicitonary, [] to vector etc.)? I am sorry if those questions are trivial or nonsensical... I am trying to foresee problems that we could have with boost::serialization. If you have some proposition how to solve this xml+python attribute access in a better unified way, don't hesitate to post, please. (Switching the wrapper to py++ doesn't seem very practical at the moment, as it works quite nicely the current way; (frequent) adding of a class or adding/removing attributes doesn't require the wrapper to be regenerated/recompiled at all) Regards, Václav Šmilauer