David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
Also, following Dave's proposal none of your archives is touched, but instead additional faster ones are provided.
This wasn't clear to me from my reading of the proposal.
Regardless of whether it _was_ clear, can you now accept that there is **no proposal to modify the serialization library** ?
As has been surmised, I did overlook that fact that although certain things had the same names the were in different namespaces. So that will resolve some confusion. OK that's fine. Now my question is why do you need anything from me?
As stated several times, we presented the simplest thing that we think can address the problem **without modifying the existing library**.
Ahh - I think it can be simpler. That's the rub.
Even thinking of that code as a proposal is a little bit wrong. We'll need that code (or something very much like it) in order to provide fast array serialization. We're _going_ to provide what's in "the proposal" (or something very much like it) one way or another, either within Boost or elsewhere. We could put that code in our own library, which we could submit for a separate Boost review, or we could publish it separately.
I have absolutely no problem with this. In fact, I look forward to seeing people come up with more and more archives. As I said in another post, I don't see the archives currently included with the package as really part of the library - but rather examples of how the common code can be used to build an archive class suitable to the purpose at hand. So I see no conflict here at all. In fact I see this as complimentary to my goal of narrowing my area of responsability as it regards the library. Of course, some people will use the facilities to undertake efforts which I consider misguided. I'm not hugely happy about that but I just have to live with it - and who knows I might be wrong. But since those people are investing their own effort its their call and I'm fine with it.
We took special pains to conform as closely as possible to your expectations and requirements for code that could be part of the serialization library, but only to make it as easy as possible for you to understand what we're doing. After going to such great lengths to be understood it's very disappointing to have failed so miserably. I hope you can help rescue our efforts by making a commensurate effort to receive our postings as they are intended, rather than as... something else.
Well, I concede I've misunderstood some of the things you're doing. Shortly, I'll post some code that I believe addresses all your design goals in a much simpler and effective way. That may be helpful in resolving this misunderstanding. Robert Ramey