Edward Diener <eddielee@tropicsoft.com> writes:
Let me try to understand this. Are you saying that you ( the proverbial 'you', not the personal 'you' )
I don't know what you mean by the "proverbial you;" I can only answer for the "personal me."
would take a library that someone else had developed, even if it is admittedly in the public domain, and propose it as a standard library to the C++ committee, making whatever changes might be necessary to get it accepted ?
Yep. Of course the original author would be duly credited for his or her work. I'd certainly let the author know what I was doing, and if she or he objected I would certainly try to understand the reasons for the objection, and I might think twice about proceeding.
I am asking this quite seriously and not facetiously because for my own Regular Expression Component Library I took an earlier version of Boost regex++, made some small additions and changes to it, and incorporated into my own non-templated library interface which I have made available freely. I felt justified in doing this not only because Boost tells me this is legally OK but also because John Maddock generally understood what I was doing, and was helpful to me. But I would never have thought that it was right proposing my own slightly altered version of just the regex++ part of it to the C++ standards committee if John Maddock hadn't proposed regex+++ himself ( and of course a much improved regex++ than what I had used ). It still seems clear to me that if a public domain library developer wanted to have his library accepted as part of the C++ standard, that is his prerogative, not someone else's, and that attitude is a personal one not a legal one.
I still don't know why it's clear to you, but perhaps it's just one of those things that has to be taken on faith.
I also can anticipate problems having someone else propose the library, and I am not talking about anything having to do with the effort of understanding internally how the library works.
That's good, because internals (apart from implementability) are not all that relevant to standardization.
The biggest problem centers around changes that might have to be made in the library to satisfy the C++ standards committee. Once those changes are made there are now two stewards to the library and two slightly different versions of that library. I do not think this is a good situation. One now gets into arguments about what is better, which direction new decisions and designs should take, and the rest of that rigamarole which means difficulties and arguments to no good end.
I understand your worries, but these things usually work themselves out. I don't want to suggest that your concerns are entirely unfounded, but at the same time it's easier to worry than to begin a proposal ;-)
In the current Boost model, a single developer creates a library and others are free to chime in with suggestions, discussion, and even bug fixes, but it is still the resposnibility of that developer to be the author of that library. I like that model and only in vary rare situations, like with you and Aleksey with MPL, is that model different.
How is it different there?
For these general reasons I see it as a distinct disadvantage for having someone propose a library which they themselves have not developed.
I guess you have to decide whether those risks are worse than the risk that no serialization library would be standardized.
If Mr. Ramey were to say to me, go ahead and propose the library to the C++ standards committee, it is your call to learn the library and make whatever changes might be necessary to have it accepted, I would do it. But I do not know him and he does not know me and I would not want to put him under any pressure regarding this.
That's very considerate. Really. But I doubt anyone whose library has successfully been through a pair of failed/accepted Boost reviews is going to be made very uncomfortable if you ask him to let you propose his interface design for standardization.
I still feel very strongly that serialization should be part of the C++ standard so that instead of having every C++ implementation invent their own individual methods of serializing data to and from some persistent store, as many RAD and semi-RAD environments now do, there would be one standard way of doing things in this area. Needless to say a standard C++ library for serialization would also admirably serve the purposes of data transport between systems where the language is C++ on both ends.
I guess you have to decide how to balance your various considerations. Good luck! -- Dave Abrahams Boost Consulting www.boost-consulting.com