Re: [boost] [serialization] Proposal for an extension API to the Archive concept

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-09-28 03:32:51

Robert Ramey ha escrito:

> > To sum it up, what I propose is to go from situation 1 (your proposal)
> > where:
> >
> >   1. The Archive concept does not guarantee serializability of
> >   shared_ptrs and types relying on the helper API.
> >   2. There are archive implementations which support an extension of
> >   the Archive concept by which shared_ptrs and helper API are
> > supported.
> >
> > to situation 2 where:
> >
> >   1. The Archive concept is sufficient to guarantee that shared_ptrs
> >   and types relying on the helper API are serializable.
> >
>
> > Did I get my point through so far? I'm not trying to convince you now,
>
> Suppose we just reverted to 1.34 and documented the helper interace.
> How would you proposal be different than this?  That's what I'm missing.

Well, it depends on whether you state that all conformant Archive types
must be implemented by deriving from common_{i|o}archive or not. If derivation
from common_{i|o}archive is a requisite for conformance to the Archive
concept, then there would be little *conceptual* differences between that
situation and my proposal.

This is a question for you: In 1.34, is an archive type *required* to derive from
common_{i|o}archive to comply with the Archive concept?

I'll try to summarize here the different approaches, past, present and proposed,
that we have discussed so far, along with their implications regarding serializability
of shared_ptrs and other types relying on the helper API. I'd be grateful if you
can review the table and confirm whether you agree with it (leaving aside which
option you favor, I'm here mostly interested in a correct description of the
options):

A) Situation in 1.34
  * Archive types are not required to derive from common_{i|o}archive.
  * common_{i|o}archive provides undocumentedly the helper API.
  * shared_ptr is not Serializable formally speaking. It happens to be
  serializable for common_{i|o}archive-derived archives only, through an
  undocumented interface.
B) Situation in 1.34, bis
  * Archive types *are* required to derive from common_{i|o}archive.
  * common_{i|o}archive provides undocumentedly the helper API.
  * shared_ptr is Serializable. It happens to be serializable through an
  undocumented interface, so no other type can formally speaking use
  that API.
C) Situation in 1.34 + documented helper API
  * Archive types are not required to derive from common_{i|o}archive.
  * common_{i|o}archive provides the documented helper API.
  * shared_ptr is not Serializable formally speaking. It happens to be
  serializable for common_{i|o}archive-derived archives only, as well
  as any other type relying on the public helper API.
D) Situation in 1.34 + documented helper API, bis
  * Archive types *are* required to derive from common_{i|o}archive.
  * common_{i|o}archive provides the documented helper API.
  * shared_ptr and any type relying on the public helper API are
  Serializable.
E) Situation in trunk
  * Conformant Archive types are allowed not to provide shared_ptr
  support (e.g. naked_* archives).
  * shared_ptr is not Serializable formally speaking. It happens to be
  serializable for some archives only, through an undocumented interface.
  * No helper API provided.
F) Robert's proposal as of 2007/09/08 (http://tinyurl.com/2dfa3m )
  * Conformant Archive types are allowed not to provide shared_ptr
  support or the helper API (e.g. naked_* archives).
  * Some archive types do provide shared_ptr and helper API, though
  this is not a requirement of the Archive concept.
  * shared_ptr and any type relying on the public helper API are
  not Serializable formally speaking. They happen to be serializable
  for some archive types only.
G) Joaquín's proposal as of 2007/09/26 (http://tinyurl.com/2tuucq )
  * Conformant Archive types are required to provide an extension
  API ({get|set}_extension_obj). This constitutes a revision of the
  Archive concept.
  * B.S provides shared_ptr support and the helper API.
  * shared_ptr and any type relying on the public helper API are
  Serializable.

I've tried to describe the options as dispassionately as I could, so as to
lay a common ground for further discussion. Do you see any error
in the description? Are you satisfied with this rendering of the available
options?

> Of course it would mean an expansion of the Archive Concept for just
> one data type.

But an important one (and more are coming, e.g. std::tr1::shared_ptr).
You are of course free to avoid expanding the Archive concept as
in E) and F), but the logical implication of this is that shared_ptr is
technically not serializable. Nothing wrong about that, if that's your
declared intention, but users should know.

> Another layer of concept for users to (mis)understand and ask about and
> whatever.

That's the job of a lib maintainer. I hope you assess every possible
extension to your library on the basis of its technical merits. If you plainly state
that B.S is closed for extension, well, this discussion is moot.

> And there will always be data types whose authors
> don't wish to expose enough functionality to be compatiable with boost
> serialization - so were does it end?  And all this for just one such
> datatype so far?

In my particular case, I can assure you that the need of a helper API
is a genuine one: I cannot serialize my type efficiently without that API,
no matter how much I want to expose the guts of my type for serialization
purposes. Please believe me on that, this is not a case of me wanting to
keep my type encapulated, "pure", or anything. It's sheer impossibility
to do it otherwise.

Of course, coming up with some more types that could put the helper
API to good use would strengthen my position, that' for sure.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo