Preston A. Elder wrote:
Any ideas, etc. would be welcome.
I'm not exactly sure what you're trying to do - but no matter here's my idea anyway. create a TEE type streambuf. This would model the std::streambuf that the standard library uses. It would most likely be built with the i/o streams library. All date written to the streambuf would infact be written to multiple stream implementations. This would get you replication for free. In fact, what would be more useful would be an i/o stream adapter which would take any number of streambufs and compose them into one TEE type streambuf. This would permit one to leverage on all the streambufs already created. It would mean that the the streambufs would all have to be the same type. Some could be binary, others could be file bases, others could be network connections, etc. This is something that could/should be added to the i/ostreams library - if it isn't already there. The counter part of this - reading back one of the archives in the same application would read one of the streams in the TEE. Remember that all information concerning the state of the archive, addresses of created pointers etc, class i/d, etc is local to the archive. So there would be no conflict.
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?
So I don't see serialization as the right place to implement such functionality.
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.
LOL - The reason the interface is "fantastic" is mainly due to my single minded dedication to keeping it that way. The way I've done this is to keep everything out of it that can possible be put somewhere else. I realize that this sometimes might seem limiting - but in fact its liberating. It has kept serialization from turning into he C++ equivalent of Microsoft word - where it would do everything everyone wanted if anyone could ever figure out how to make it do what it is they want. In spite of this, the serialization library implementation is still quite complicated. I have toyed with experiments to make the serialization library more useful for things like logging, rollback and recovery. But the experiments have been unsucessful so far in that the end up either making the library harder to use or less efficient. If I had nothing else to do, (or someone was paying me to do this) I might spend more time at it. But for the near term I don't see any functionality being added to the serialization library. I spend the time I have on incremental efficiency improvements and keeping it buildable in a changing infrastructure (bjam v2, new test library, new compilers - borland) etc. I'm pleased you seem to like the library and have found it useful. Robert Ramey