Re: [lmi] Boost serialization library

[Vadim Zeitlin]

On Thu, 27 Nov 2008 00:44:52 +0000 Greg Chicares <address@hidden> wrote:

GC> Recently, Vaclav mentioned the idea of using the boost serialization
GC> library instead of 'ihs*pios.?pp', and I wanted to share my thoughts.

 Hello,

 I'd like to add the few extra ones (and sorry for the time it took me to
gather them) as I did consider the use of boost serialization library
several times. All in all I think it's a good library but I finally never
really used it... Here is a list of things which influenced my decision,
roughly in order of importance:

- The main problem was the choice of the archive format: the library
  doesn't have a portable binary format at all so this wasn't an option
  anyhow. OTOH its text format is portable but pretty unreadable and,
  worse, hardly modifiable at all. This was a huge drawback for me as I
  really want to be able to edit my config/data files in Vim, otherwise
  what's the point of using text. There is XML, of course, but I'm not
  especially enamoured of it and would prefer to have some simpler
  (YAML-like) text format using named fields.

- The design goals as stated here
  http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/index.html
  cover much more than I needed and while this doesn't hurt in itself it
  probably does mean that my needs could be addressed by much simpler
  libraries. For the record, I consider the points (1), (7), (8) and (9)
  indispensable and (4), (6), (10) and (11) nice to have.

- Speaking of named fields, I don't really have any better suggestions but
  using BOOST_SERIALIZATION_NVP() everywhere just seems too ugly. I also
  find the use of operator&() rather gratuitous and even though you can not
  use it all, of course, it still seems like a bad idea to encourage it.

- I was not sure if this library is still actively maintained/developed. It
  seems that some work has been done on it since the last time I looked and
  there were significant changes as recently as in Boost 1.35 (see
  
http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/release.html#differences_1_35)

- I wasn't impressed by the documentation. There is quite enough of it but
  it's a bit chaotic (although this is still probably better than dry,
  standard-like description of some other Boost libraries) and there are
  plenty of typos and some other stupid mistakes. It's notable that even
  the URL above refers to "TRAK" instead of Trac -- this is, of course, a
  perfectly harmless mistake (even repeated several times) but I find the
  lack of attention to details a bit worrisome.

GC> We don't need all the fancier persistency features, e.g., deep pointer
GC> save and restore. Here are the attributes that seem most desirable:
GC> 
GC>  - The format should be xml.

 This is covered.

GC>  - The particular xml format may matter for the practical purpose of
GC>    compatibility with existing files, especially if we can use the same
GC>    library for input. However, one xml format can be translated into
GC>    another, so that shouldn't be a serious obstacle.

 I wouldn't assume that it's necessarily easy to do.

GC>  - "Versioning" is crucial, and it's good to see that the boost library
GC>    addresses it.

 I had trouble seeing how would versioning, as implemented by this library,
help me with any problems in practice. I agree that versioning is important
but it's rarely (never IME) as simple as just omitting loading some field
when restoring from an old format.

GC>  - Run-time speed.

 I didn't notice it being obviously horribly slow although I'm quite sure
that the simple code I wrote to do serialization to replace it was faster.

GC> I recommend we proceed with some experiment to ascertain whether this
GC> boost library is suitable for our grand purpose of reading and writing
GC> xml files in a consistent way.

 It's definitely not suitable for reading/writing _any_ XML files. It can
only work with formats like this

http://www.boost.org/doc/libs/1_37_0/libs/serialization/example/demo_save.xml

at least using the provided XML archive implementation. It should be
possible to define another one for custom formats (although I didn't try
doing it) but it still seems to be wrong to try to use this library if you
want to use a more or less fixed XML format.

GC> Sorry if this seems noncommittal, but the last time I endorsed a novel
GC> approach without exploring its "unknown unknowns" was here:
GC>   http://lists.nongnu.org/archive/html/lmi/2008-11/msg00003.html
GC> and I'm eager not to repeat that costly mistake.

 I was afraid of making a mistake in choosing Boost serialization too and
doing it myself was finally just much less risky as I was pretty sure that
I could do it in (limited) time I had. But then my needs were simpler than
those of LMI and also less well aligned with this library strengths so
finally it could be a good choice in this situation.

 Sorry for being even more noncommittal than you, rereading this message
I'm not sure any more if it's really going to help you to take the decision
but I'm still going to send it on an off chance that it might.

 Regards,
VZ