From: Robert Ramey (ramey_at_[hidden])
Date: 2006-04-10 13:17:38
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
> 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
>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
dedication to keeping it that way. The way I've done this is to keep
out of it that can possible be put somewhere else. I realize that this
might seem limiting - but in fact its liberating. It has kept serialization
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk