Re: Boost persistence library

From: quendezus (quendez_at_[hidden])
Date: 2002-01-25 05:26:00

--- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> Thu, 24 Jan 2002 14:16:22 -0000, "quendezus" 
> <quendez_at_4...> wrote:
> >
> >1-
> >Is this a common need ? What should the library do ?
> 
> In applications that use objects to manage user data, persistence 
> makes saving and opening documents much easier.
> 
> It's common to use persistence to store window layouts and the 
> initial state of application objects. This makes programming 
easier, 
> and it's a huge help for internationalization.
> 
> Persistence can also be helpful for distributed objects. The 
objects 
> are sent and received, rather than saved and restored.
>

Agreed.

> 
> One thing we haven't talked about is automatically saving and 
> restoring objects. I think that gets into object database 
territory, 
> and it should be beyond the scope of a persistence mechanism.
> 

I agree with you. It seems to me sometimes you need persistence but 
don't want to deploy an object database. Robert Stewart seemed very 
doubtful about C++ persistence. Robert, could you explain your 
position further?

>
> >2-
> >I have the feeling that a persistence library would need the
> >following mechanisms:
> >- a RTTI+ system that should allow object creation at runtime, 
based
> >on type information (I call it RTTI+ to indicate that it has more
> >functionalities than the standard C++ RTTI).
> 
> It's also been called typeid_helper. The problem with basing 
> persistence on RTTI is it hard wires the record formats to the type 
> id. I've worked on systems that do this, and it's nice until you 
have 
> to interoperate with different formats, and you have to create a 
> whole new mechanism. What we really need is just an object factory 
> mechanism that allows multiple factories.
> 

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.

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.

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.

What do you think?

>
> >- a serialization system that would give facilities to serialize 
and
> >deserialize objects into a kind of "storage".
> >In my work as a developer, I need these 2 mechanisms alone more 
often
> >than a persistence library. But anyway, I don't think it is 
possible
> >to make a persistence library without them.
> 
> That's right. That isn't quite the same thing I want to do, but 
they 
> don't necessarily conflict. I don't see a huge difference between 
> serialization and persistence. Persistence is just serialization of 
> pointers, allowing for all the things that can happen with pointers 
> such as polymorphism and sharing.
> 

I understand. But it seems to me serialization (or static 
serialization as you say at the end of your message) by itself needs 
a lot of work: what about binary portability? Which relationship with 
<iostream>? 

Sylvain