Re: [boost] Re: Boost persistence library

From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-01-26 03:12:49

On Saturday, January 26, 2002, at 01:36  AM, Tom Becker wrote:

> On Fri, 25 Jan 2002 10:26:00 -0000, Sylvain 
> <quendez_at_[hidden]> wrote:
>> I think I understand your point: you are saying that the persistence
>> mechanism should work with arbitrary type formats, and even with
>> multiple type formats. And so you want the persistence layer to
>> manipulate an abstract factory mechanism, configured by the user. In
>> theory, I should agree with you, but here is my reasoning:
>>
>> 1- You speak about multiple type formats, but what about
>> standardization? Maybe a boost library could decide for a format
>> (given that one format can fit all needs). If one format is accepted,
>> this simplifies a lot the interface of the factory system.
>
> I'm all for promulgating a standard format. But as old programmers
> know all too well, existing data formats will never go away. If we
> can have a single library that can easily be adapted for different
> formats, programmers will want to use it, and once they are using the
> library, they will have a much better chance of seeing the advantages
> of using the library's standard format.
>
> A flexible serialization library could replace a lot of proprietary
> code that's out there in the application frameworks. As someone who
> has worked on a framework, believe me, this would be a good thing.
>
> One thing that happens when a framework or an application has been
> around for a while is the data formats evolve. Having some support
> for multiple formats, or at least versioning, is a good thing.
>
> The strongest reason, for me personally, is there's an application I
> want to write that will have to interoperate with a wide variety of
> persistent object formats.
>
> I think the library should be forced to prove that it can handle a
> wide variety of common formats, and it should also be simple and well
> modularized. It should not require developers to learn about or pay
> overhead for features they don't use. In my experience, the best way
> to get to a really elegant solution is to try a lot of different
> variations, see where the problems are, and keep pounding on the
> design until it handles every variation in a clean way.

I agree completely. We need to support a variety of data formats
to interface with other applications. In our case we need
text-based formats for testing and debugging, binary formats
based e.g. on XDR for interplatform-compatibility, and other
formats such as HDF-5 for interoperability with other programs.
In addition we use it for message passing. Thus support of a
variety of formats is essential. Versioning is also important,
as formats do indeed evolve over the years.

On the other hand a default format for binary files will also
be an excellent idea.

>
>> 3- Given points 1 and 2, I don't think abstraction is needed between
>> the factory and persistence layers. For me this would only make
>> things more complicated.
>
> There should be a low overhead solution that makes you happy. There
> may need to be some other stuff so I can be happy too, but it should
> be optional and not get in your way. I hope that you will continue to
> be involved in this discussion. Your questions have been very helpful.
>
> I think we're at the point where it would make sense to start talking
> about actual designs and code. Unfortunately, I don't have a lot of
> free time at the moment, so it's going to be a little while before I
> can post anything. Maybe there are others who have stuff they'd like
> to put forward.

I could post my old library we are using now. It is by no means perfect,
nor should it be used as a starting point but shows the features we need.

Matthias