Boost logo

Boost :

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2002-12-13 19:04:24

Dave Harris wrote:
>> Me: I'm not sure what kind of generic versioning we can provide.
>> What benefit do we provide over the application author
>> serializing/deserializing his or her own version?
>Java does quite a lot in this line. It has enough metadata
>both of the running program and in the archive, to be able to detect
>missing or surplus fields, changes in inheritance hierarchy etc, and
>fix them up. Many tagged formats (including XML and RTF) are
>to allow unexpected or unknown fields to be skipped during loading.

Formats that archive meta-data could, at thier option, provide some
intelligence to handle meta-data mismatches. I like that. Not all
formats will store meta data, though. What will any framework ever
be able to do when you try and load a v2.3 class into a v3.2 class?
2.3 and 3.2 mean nothing to the framework, except they're different,
so you can generate an error.

This just occurred to me: maybe versioning should be left up to the
formats rather than being part of the framework? Once a couple of
formats are written that use meta-data, maybe we'll find common
version matching/recovery code that can be factored out.

>This would mean reading all the data in advance and storing it in
>kind of tree structure. The UDT code shown would actually traverse
>tree and use random access at each node.

Not all mediums would be able to support non-serial behavior, forcing
you to cache it in memory as you suggest. I think the answer would
be to serialize/deserialize your tree structure, and then initialize
your objects from the tree. Maybe this would be a good example usage
of a serialization library? At any rate, the logic for recovering
from meta-data mismatches is part of this tree, not intrinsic to


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

Boost list run by bdawes at, gregod at, cpdaniel at, john at