[boost] Re: persistence

From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-25 20:00:22

I think a persistence library for Boost would be fantastic.  I belive 
your schema approach -- compiling a schema into C++ code -- is the right 
one.  Some thoughts on requirements for an ideal C++ persistence library:

* use an XML schema, but some schema information, perhaps in another
   file, support C++ specific issues (e.g. does the data go into a list
   or a vector?)

* support both XML and binary data formats

* support both native-only (useful for IPC) and cross-platform formats

* support for "integrated header files" -- that is, rather than
   generating a C++ header, it should be possible to use an existing one
   (allowing you to customize it).

* support for complex data structures, including recursive structures.
   It should be possible to re-establish pointers, in other words.

To me, that would be the holy grail.  It should probably be developed 
like the thread library, though -- start with core capabilities, then 
build on it over time.

I've love to take a gander at your code...

     - Chuck Messenger

Scott Woods wrote:
> Hi,
> Is anyone interested in a persistence mechanism? Rather than dumping a bunch
> of doc+code and finding that its just inappropriate, here is some summary
> stuff.
> 
> Technique uses info available in a variant to manage the type-safe transfer
> of
> data between an application and some external storage. It can be
> characterized
> as a replacement for the windows registry or unix profiles. The technique
> has
> following properties;
> 
> * generic - load and save operations are templates
> * portable - library and data are not platform dependent
> * standard types - bool, integer, float, string, etc
> * complex types - fixed dimension arrays and variable dimension vectors
> * user-defined types - records (a set of members of any type)
> 
> Simplest usage involves "hand-forming" the variants. This is a bit
> long-winded
> (and error-prone) so a "compiler" has been developed. This accepts a
> "schema"
> conforming to a grammer and outputs a set of C++ classes (cpp and header).
> The application can then derive application classes.
> 
> Given an application class "alarm_monitor" the schema might look like;
> 
> record sensor_signal {   // Generated by raising the signal on an alarm
> sensor
>  time when     // Instant of detection
>  string line     // Expanded text
>  void detail[]
> }
> 
> record monitor_store {   // Persisted image of a monitored sensor
>  integer number    // Unique id
>  integer status    // Currently
>  sensor_signal log[]   // Rolling log of signals
>  integer ring_count   // Signal count since last ringing transition
> }
> 
> The application would derive "alarm_monitor" from "monitor_store" and a
> minimal
> ctor might look like;
> 
> alarm_monitor::alarm_monitor( const alarm_sensor &sensor ) :
> {
>     try
>     {
>         // Recover the previously saved image of "this"
> 
>         typed_load_file file( sensor.name );
> 
>         load( file.begin(), *this );
>     }
>     catch( typed_memory_not_found & )
>     {
>         // No previous image. Set the members of "this"
>         // to reasonable defaults and save an image
> 
>         number = sensor.number;
>         status = monitor_ready;
>         ring_count = 0;
>         log.clear();
> 
>         typed_save_file file( sensor.name );
> 
>        save( file.begin(), *this );
>     }
>     // Resume normal operation
> }
> 
> Hope this is enough info. Code is currently getting a good workout (part of
> beta
> in a 24x7, server-type product). Example above is "para-phrased" to keep it
> short and to remove some confusing coding standards.
> 
> Thanks,
> Scott
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>