Re: Boost persistence library

From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-25 19:36:33

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.

>2- I think RTTI+ (or typeid_helper) is by far the best way to
>implement the factory mechanism. This allows to benefit from the C++
>RTTI and thus to provide a non intrusive system. We should discuss
>this more. If one implementation is better, there is no need for an
>abstract system. A concrete one will do.

I agree that RTTI can be very helpful in this context, and there 
should be a mechanism that leverages it. I just don't want to 
position it as an extension of RTTI. This may be more of a semantic 
and philosophical perspective than an actual practical design issue.

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

Regards,

   Tom

-- 
Tom Becker                      "Within C++, there is a much smaller and
<voidampersand_at_[hidden]>        cleaner language struggling to get out."
                                                       -- Bjarne Stroustrup