Manfred Doudar wrote:
The main point is - do enhancement for special cases have to be incorporated into the the core code so that everybody else is obligated to use it? What are the advantages and disadvantages of doing so?
Umm, I don't follow - how are others going to be obligated to use those special cases that don't necessarily apply to them?
The design of the original submission changed binary_archive so that everyone would benefit from the enhancement whether they asked for it or not. The library has been designed to avoid exactly that situation.
No one is disputing that it desireable to be able to extend the library for these special circumstances.
Actually it's *very* desirable.
The library has been designed to permit this. I don't see how anyone who looks at the documentation could conclude otherwise.
If there is to be any possibility of targetting an archive to this format, then array support is crucial.
Then just make an archive which does it- what's stopping you?
True - but the suggestion is that it's common enough to want as part of the core library.
Ahhh - perhaps this is the source of the confusion. When I use the word "core library" I'm refering to the common set of facilities that ALL archives use. For example, xml is not part o the core library - though its widely used. xml_archives have been build on top of the "core" and are in fact a use case for the library. Of course, users who don't build archives themselves may not be aware of of and see xml_archives are part of the "core library" because its included in the package and they just use it. The library is really an archive construction kit. As part of the package it includes 5 pre-made archives which a) can be used as is b) can serve as examples for making one's own archives c) can be used as base classes for making variations and extentions d) can be composed with archive adaptors to create variations of existing archives - e.g. polymophic archives. The current situation is where one user feels he needs to to something that none of the other archive creators have had to do - alter the construction kit itself. This violates the factoring which has permited the library to be used to make all these different archives from the same core layer. This same factoring has permitted the implementation of polymorphic versions of all the above 5 archives and will permit any new archive to be made polymorphic by composition with existing code. ****************************************************** *So for the Nth time. This is not about whether or not archive *XDR, CDR, MPI, or XYZ should be made. Anyone is free to make it. *Its about how to do it so that it doesn't impact anyone else's efforts. ****************************************************** <snip> about how important other formats are </snip>
I've been loosly following this thread and I understand your reluctance to this - but it's a matter of perception as to how needful, and widespread such a need is.
If there is a need, I trust someone will make the corresponding archive. If its too hard to make an archive - well that's another problem and I'll see how that can be made more transparent. Robert Ramey