Re: [boost] [Boost Review] Do property_tree and program_optionsoverlap?"

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-05-01 08:12:54

Hello Brian,

----- Mensaje original -----
De: bwood <brass_at_[hidden]>
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