From: Dave Harris (brangdon_at_[hidden])
Date: 2002-12-14 08:48:37
On Fri, 13 Dec 2002 16:04:24 -0800 (PST) Augustus Saunders
> 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.
I wouldn't want an error if I have written my UDT code to convert the old
> This just occurred to me: maybe versioning should be left up to the
> formats rather than being part of the framework?
That's what I had in mind. There needs to be some API to make meta-data
available, but it's up to each format to decide what to do with it. Some
will ignore it and not store it, some will store it and just verify it is
the same during load, some will rely on the UDT to do any checking and/or
conversion. Possibly some will attempt conversion themselves.
> 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
That would be a possible fall-back approach. My hope was for the tree to
be managed by the format subclass, /transparently/ to the UDT code. The
UDT should not need to know whether the format is sequential or random.
It's intrinsic to serialisation in that it is something the framework
ought not to prevent; it is a fairly demanding constraint on the API. It
is optional in that it is a scheme which only some archive formats would
adopt. It would be nice if the library included at least one format which
used it, to demonstrate proof of concept.
-- Dave Harris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk