I also have another follow-up question, regarding the same thing. I'm pretty sure this is possible by reading the docs, but its not a documented feature (I'm not surprised, really). How do I do the equivalent of a la.reset_object_address(v, u) for an object that has NOT been serialized with that archiver? The situation is this, I will obviously have to have an iarchive and oarchive class - to accomodate failing over between instances of my application (remember, my [io]archive instances will remain active throughout the application). Therefore, when I send something to an oarchive (ie. the primary replicating 'out'), I also need to add that reference to the pointer tree maintained by iarchive. Similarly, when I receive the item via. an iarchive (ie. the secondary replicating 'in') I need to add that reference to the pointer tree maintained by oarchive. If I could make an iarchive and oarchive use a common pointer reference tree, that would be ideal (I'm not very worried about thread safety since only one would use it at a time), however if not, I need to keep the complementing object references up to date in case of fail over. Why? Because if my primary goes down, and I fail to my secondary, it now becomes the 'master' and starts replicating out itself. Because of this, it needs to be able to pick up where the old primary left off (both in case of any tertiary instance listening, and because if the primary comes back up it will want to be replicated to again, becoming the secondary). The more I think about this, the more it seems I'm trying to hammer a round peg into a square hole - especially considering I know that each tracked object is assigned an ID, and that ID would have to be maintained between the iarchive and oarchive instances to be able to change from a consumer into a producer like that and have third party consumers not notice the difference. Any ideas, etc. would be welcome. Also, might I make a request to the maintainer of serialization to hopefully turn boost::serialization into something that can be more suitable for replication purposes in a future release of boost? The interface of boost::serialization is fantastic, but the implementation I think needs a few more knobs and switches to enable a wider variety of purpose. -- PreZ :) Death is life's way of telling you you've been fired. -- R. Geis