Re: [lmi] Boost serialization library

[Greg Chicares]

On 2008-12-30 17:42Z, Vadim Zeitlin wrote:
> On Thu, 27 Nov 2008 00:44:52 +0000 Greg Chicares <address@hidden> wrote:
>
> 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.

Unless Vaclav disagrees, it seems to me that your analysis
is adequate for us to conclude we should do it ourselves
instead of using this library.

At least for the long term, that is. I remain open to the
idea of a two-step change:

 (1) Replace 'ihs*pios.?pp' with this boost thing for now,
     in order to get rid of the former immediately--but
     only if run-time performance isn't unduly harmed.

 (2) Then get rid of the boost thing and do it right.

That doesn't appeal much to me, but it might be less bad
than hacking 'ihs*pios.?pp' to work with a 64-bit OS,
which IIRC was the original motivating idea.

>  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

For example:

<boost_serialization signature="serialization::archive" version="3">
<s class_id="0" tracking_level="0" version="2">
  <schedule class_id="1" tracking_level="0">
    <count>6</count>
    <item class_id="2" tracking_level="0">
      <first class_id="3" tracking_level="0" version="3">

Yikes. Sure, it's a step forward from this, I guess:

/opt/lmi/data[0]$od -t x2 sample.db4
0000000 013a 0001 2e00 0001 0200 085b 0000 5400
0000020 4244 6156 756c 0165 0000 0000 0000 0700
0000040 0000 0100 0000 0100 0000 0100 0000 0100
...
0057260 0000 0000 0000 0001 0000 0000 0000 0000
0057300 0000 005d

...but I'd rather have something as plain as this:

<item name="MinIssAge" definition="Minimum issue age" rank="scalar">
    15
</item>

(or plainer).

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

Well, I sure don't want anything like this:
  <item class_id="2" tracking_level="0">
    <first class_id="3" tracking_level="0" version="3">

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

I keep coming back to this:

  http://www.joelonsoftware.com/articles/fog0000000007.html

especially because it's the lmi product-database class we're
talking about, to which architect-wannabees always say:

  "You wrote a database from scratch? That's madness!
  You should use [insert name of whatever bletcherous
  database-to-end-all-databases is in vogue] instead."

The answer, of course, is that mine is simple, small, fast,
and correct, and hasn't needed maintenance for ten years.