Hello Brian, ----- Mensaje original ----- De: bwood <brass@mailvault.com> Fecha: Lunes, Mayo 1, 2006 0:45 am Asunto: Re: [boost] [Boost Review] Do property_tree and program_optionsoverlap?" [...]

Please correct me if I'm wrong, but it seems B.MI's serialization forces you to receive a B.MI instance with the same number of indices as was sent.

Correct. In fact, you're required to use the very same type (i.e. container definition) on loading that you used on saving.

While on one level it is impressive that B.MI preserves the relative order of equal elements, it has a cost. If you have a B.MI with 3 indices in a server and only need one or two indices in a client, you have some work to do. In order to accomplish this I think you would have to receive a B.MI with the same indices as was sent and then write code that copies the contents of that B.MI to either a simpler B.MI or an STL container. Does the preservation of the relative order of elements matter more than this sort of flexibility?

Well, my approach to B.MI serialization looks to me a natural one, in which if one saved a T then it is a T that it must be loaded. AFAIK there's no scenario (excepting this discussion) where loading Qs from saved Ts is ever considered. Now, I'm not denying the potential usefulness of a serialization approach like you propose: it is just that I don't have any feedback about how B.MI serialization capabilities are being used to make an educated decision, and what I settled for has at least the benefit of consistency with other serialization implementations. In the meantime, it is easy to have less stringent serialization of B.MI containers by simply saving their elements according to its first index (similarly to what your own middleware service does), which can be implemented without built-in support from B.MI itself. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost