RE: [boost] Serialization Library Review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-11-24 13:49:12

Robert --

A few thoughts...

> Well, I havnt actually counted up the votes but
> the concensus seems pretty clear that it shouldn't
> be accepted into boost as is.

Yes, but it isn't consensus that matters.  In fact,
the whole decision rests with Dave.  He takes into 
account all of the information and makes the decision.
So the vote might be 10 against and 5 for and Dave
might decide to accept based on the quality of the
5 'for' votes.
 
> Of course I'm disappointed.
> 
> Now the question becomes whether its possible to
> make changes such that it would be acceptable.  In

In my mind there is no question that this can be
done.  I feel sorry that there wasn't more active
participation in looking at your library in advance
of the review.  

> I havn't done an exact count, but its seems that the library would
> not meet the approval of boost in its current form.  On the otherhand, 
> it seems that a significant number of boosters like much about the library.
> 
> I am very interested in getting this into boost for a number of reasons
> a) I would be personally gratifying to me to earn the approval of those
> whom I would like to think are my peers.
> b) it would be good for my career as a contract software developer.
> c) I believe this is a good implementation of a facility which would be
> a valuable contribution to the boost library.
> d) it has me by the throat.
> 
> 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.

My understanding is that you would have to survive another 
round of reviews, but I'm not sure about that. Obviously, by 
facing and resolving these issue you will gain much more support.
But I don't know that anything is guaranteed.

> 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 don't think the 'guarantee' of XML would take much change -- I know you
are worried, but I think it is really only hooks for the start and end
of composites.  The ability to add in a 'reflection package' is a need, 
but I don't see why you need to do this work.

> 7.0 Miscelleania
> ================
> Boost is really missing a key thing to finish off a package like this as well
> as other boost packages.
> 
> Boost needs designated "platform gurus". One for each platform - gcc 3.1, msvc7,
> msvc6, comeau, borland, metroworks, etc.  Once a library has been accepted
> into boost, the "platform gurus" would build and run the tests on the platform
> for which they are responsable and report back to the library developer.
>
> a) Given the current state of C++ language and the compilers that implement it,
> there is really no other way to guarentee that all libraries work on all platforms.
> b) It would be much more efficient that having the library developer going around
> trying to beg users of different compilers to help out.
> c) The system would be much more efficient in that "platform gurus" would know about
> the quirks for thier particular platform while library developer's maintainers can't
> really be expected to understand all the quirks for all the platforms.  Its the 
> M(libraries) * N(platforms) problem in a different form.
> d) This effort would be applied only after a library is otherwise approved.
> Given that the number of library actually approved per year is small, being a
> "platform guru" wouldn't be an unreasonable burden.
> d) "platform gurus" would be making a valuable contribution even though they don't have
> the time to design, build, and get approved a new library contribution.
> e) Such a valuable contribution would justify adding these people to that elite
> group known as "boost library contributor" along with the web site picture.  The
> "boost library contributor" is incredibly valuable currency.  A little bit spent
> in this direction would improve boost code alot.  Of course, the currency is valuable
> because it has been wisely spent - so far - so don't go overboard with this idea.

I think the gurus are there -- just ask. However, it would be nice if we could run 
regular builds on the sandbox to help with the porting issue.  Often you can solve
the porting problems just by looking at the compiler output.  This would mean that
authors would be less at the mercy of gurus and able to sort out the porting issues
more rapidly.

Anyway, I hope you will keep with it no matter what happens.  This is a very 
important library that many, many in the C++ community can utilize.  Going 
forward I recommend a few things:
1) If not accepted, put the library in the sandbox so that others can help 
   you more easily
2) Make sure to post updates and generate discussion on the specific issues 
   as they are being resolved.
3) Keep in touch with those folks that are trying to use or extend the library
   and get them involved in moving things forward.

Jeff