Re: [boost] Serialization Review Results

From: Dave Harris (brangdon_at_[hidden])
Date: 2002-12-14 08:48:37

In-Reply-To: <20021214000424.34018.qmail_at_[hidden]>
On Fri, 13 Dec 2002 16:04:24 -0800 (PST) Augustus Saunders 
(infinite_8_monkey_at_[hidden]) wrote:
> 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 
format.

> 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
> serialization.

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