Re: [boost] Serialization Library Review

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-25 03:08:32

Robert Ramey wrote:

> b) Some posts suggested alterations in libary interface to
> permit a specific usage of the library.  These were of the character
> as "required to implement bracketing for XML" etc.  My view
> is that it dangerous to alter the library interface to
> accomodate speculation about future directions.  I would
> much prefer that some take a copy of the library, develop
> his new "thing" making necessary changes in the libary.

As many persons said, this should be very simple. OTOH,
it's fair that you want interested persons to do it,
rather that hacking on a feature you'll never use.

> The new "thing" then gets judged on its own merits taking
> into account the impact that it would have on the library.
> I don't think this places any extra burden on the inventor
> of the new "thing" and prevents us from making the library
> from being harder to use to support features that arn't
> added yet.  

Frankly speaking, I have one concern. We (you and I) seem to
have problems understanding each other. Therefore, if I
implement something after the library is accepted, it
may be hard to convince you to adopt the change. I may be
mistaken, but this is how I feel. Anyway, see below.

> 5.2 "registration" - A brief recap:
[snip]
> Red Herrings
> ============
> a) it has been aledged that the forward declaration method
> will preclude archives written by one program being read
> by another.  I don't know what the basis for this belief was
> but in anycase it is demonstrably false. 
> http://aspn.activestate.com/ASPN/Mail/Message/1354725

I believe "demonstrably false" is quite a questionable phrase,
both in correctness and politeness. Can you provide any proof?
And what's your opinion on

http://aspn.activestate.com/ASPN/Mail/Message/boost/1433616

The message talks about two version of the same program,
but you can easily adjust the example.

> Is it possible to reconcile these differing points of view ?
> ============================================================
> I was not at all prepared for the stridency of the arguments surrounding
> this issue.  I truely regret using the term "registration" and 
> "register_type". I believe this has contributed to what I see as a huge
> amount of misunderstanding as to where type ids fit into this
> system.  I also confess that I had recognized that someone
> might object to the "forward declaration" so I sort of de-enfasized it
> in the hope that it might pass "under the radar" with just a little
> grumbling.  BIG MISTAKE. Oh well.
> 
> After much thought, I have come conclude that it is possible
> to accomodate the global register idea in a way that
> does not complicate the system too much.  Basically it would
> create a "function" implemented by the preprocessor that looks like
> 
> #define SERIALIZATION_GLOBAL_REGISTER(T)\
> 	boost::serialization::instanciate<T>("T");
> 
> #define SERIALIZATION_GLOBAL_REGISTER(T, NAME)\
> 	boost::serialization::instanciate<T>("NAME");

That's mostly fine with me. Macro is not 100% needed,
you can just use "instanciate" directly. I'd also like
to have a second version of "instanciate", which does not
take an argument, and uses "type_info::name()" instead.
However, I can code that myself in no time.

> 5.3 "describe"

> I was reluctant to embark on a "whole new thing" (reflection) without having
> first finishing the thing I started out with (serialization).
> Basically, I didn't feel I could do "describe" right, so that it should
> be left for later.

That's right. I did not seen any objections to this during review. Did you?

> 5.4 "XML"
> 
> XML is going to be a lot more than just writing <classname> .. </classname>
> tags in the output data.  Some issues involved are
> 
> a) Using a system of C++ reflection to get the names of variables and classes

Or ask the programmer to do it. For some cases, this is perfectly OK.

> b) generating XML schema from some sort of DESCRIBE facility as above.  This
> basically inserts the reflection information into the XML archive

And is not needed for me, FWIW.

> c) the current library keeps track of data stored by writing class-id and
> object ids for classes and objects used multiple times. XML containing
> this type of information might not be useful to other programs that
> don't contain this serialization system which would defeat the purpose of XML.

1. The data that needs to be processed by other tools might have relatively
simple structure. But at the same time, it may be part of archive which uses
polymorphic pointers, &etc, so it's better not to restrict XML serialization
to some subset.

2. I might imagine the following code

         ghost::utils::C* c = ...;
         ar << c << c;

    producing this XML piece

     <!-- declare a class id for "ghost::utils::C" -->
     <class cid="2" name="ghost::utils::C" guid="12345678"/>

     <!-- store a pointer to C, giving it an id for further
          reference -->
     <ptr id="14">
         <object cid="2">
              <x>10</x>
         </object>
     </ptr>

     <!-- store the same pointer to C and use "ref"
          attribute to refer to previously saved object -->
     <ptr ref="14"/>

Here, there are two complexities
    - getting class name/guid by class id ("cid")
    - getting previously saved project by "ref".
Both operations are quite doable, if anyone wants it.

> Suppose I were to make the changes described in sections 1, 2, and 3 above.
> Would it be approved by boost?  If I could be assured that it would be,
> I would be willing to make those changes. I guess it would take me 90 days.
> 
> Suppose that the package could not be accepted into boost unless it
> included "describe" functionality and guarentees implementation of XML.
> These are two almost completely separate packages which should be separated
> from serialization.  I am not prepared to do the work as I see it as orthogonal
> to serialization itself.  It is my belief doing either one correctly is
> a is a large undertaking which I am not prepared to commit to.
> So if this is the position of the majority of boost members, I'm done.

I positively want
- a better registration mechanism (the one you've described is OK).
- hooks for XML saving
- (maybe) hooks for describe.

If you're about to create the next version in 90 days, then I'm willing to
experiment with XML and other formats that need field names. I'd be happy to 
cooperate with other iterested persons, if any.

- Volodya