Scott Woods wrote:
encoding? Given the example it would take a recompilation.
nope.
Well "given the example" - it would.
You also make no mention of my related point that there is no standard archive registry.
Honestly, I don't know what this would be and what utility it might have. Archive instatiations are local objects only.
I made the same point about a Pact version of a similar operation. It was never about whether users of Boost.Serialization could add the code you have added. It was about the fact that there is no Boost.ArchiveFactory.
I don't seen the need for any archive factory. In nine years no one has asked for such a thing either. Either because no one needs one, or making one is such trivial task.
At the important levels they are apples and oranges. When someone chooses a serialization solution out of Protobuf, Boost.Serialization and s11n they are choosing much more than a function that converts an application type to a sequence of bytes.
Hmm - I would say just the opposite. A serialization library derives its utility from it's clearly defined narrow purpose. It is for this reason that it can be used in a variety of contexts. It has been used for persistence, marshalling (e.g. see MPI library) and probably others. It can be used with any stream type. Stream types can use any encoding and (almost) any protocol.
They are choosing a model of operation for the related serialization activity.
Not here - they can plug in the other parts according to their requirements.
My response to Sohail was an attempt at saying that Pact deliberately targets runtime selection of encoding and the associated mobility of encoded data. This is within the "model of operation" for Pact.- out of the box. If I am wrong to suggest that Boost.Serialization had different design goals and consequently does not deliver this (/out of the box/) then I am happy to retract.
I think your documentation should focus more on what your library does rather than what you believe other libraries can't do. I did read through the links you posted and didn't think I could say much that would be constructive. But now that I've been sucked into the discussion, I would make the following comment. I think that your proposal suffers from a common failing that is shares with many proposals received here. It is focused on solving a fairly specific programming problem. As the work progresses, more and more "features" have to be added to make it's application wider. This often seen in commercial products which continually get bigger and harder to use. This turns out to be the exact wrong approach. A good library is simple to explain and use. When a feature is needed, it should be obvious how to compose the particular library with another one. For an example of a good library - look at iterators: a) iterator_facade b) iterator_adaptor examples filter_iterator counting_iterator .. and finally, iterators_adaptors are composable so that one can "stick" them together without re-writting anything. If I want to add some special facility (e.g. insert a space every 4 characters) I can make an iterator which does that - and compose with all the others. That's power!!! Another example - *nix text processsing tools. After 30 years grep is probably the single most frequently invoked program on the planet !!! And it's composable with all the other *nix tools. Compare this with microsoft word a behemouth which I would have to read the manual/help for a day just get the equivalent of "grep -i Ramey <my_file" | count to how many time I've mentioned my own name in this post. The classic example: algebra - four operations + ( and ) and a high school student can express a calculation which would have take euclid pages to describe. That's Power!!! That is what we should strive for. Those should be our inspiration. I realize this thinking is out of style and that I sort of got carried away. Sorry, but I feel better now. Robert Ramey