CS> I'm thinking of buying a C++ object database library such
 CS> as the "POET Object Database for C++".  There is an

 MS> a) introduction: The main problem in makeing something persistent, is
 MS> that programming language designer never thought of
 MS> such a possibility. eg. File IO is an language
 MS> enhancement in RT-libs. The early tries to overcome

While in the past I would have agreed this made sense, in the world of
object-oriented languages I'm not convinced of this any more.  Perhaps a
"cheap" way around this would be to have the compiler provide
instrinsic class methods to fill a memory block with a "packed"
copy of an object and to take a "packed" copy and change it back
into a "normal" representation of the object.  Then again, this
leaves out pointers completely -- obviously they are only meaningful if the
object being pointed at can be referenced.

 MS> b) state of the art : There are 2 different standard ways for makeing
 MS> things persistent in OO programming environment. Both
 MS> are introduced by the OMG (object management group).
 MS> One is the persistent framework (an object service for
 MS> CORBA). So, buying the IBM implementation of CORBA for
 MS> OS/2 you will get an persistence framework for
 MS> objects. For CORBA objects you define your objects in
 MS> IDL (interface defintion language) and you use the
 MS> persistence enhancements. (Note: The SOM Toolkit 2.0
 MS> contains only a small implementation of the persist.

As it looks like SOM 2.0 will be included in future versions of OS/2,maybe
this would be a good direction to take.  How much persistance support is
provided in SOM 2.0?

 MS> framework. But we will see full versions sometime.
 MS> Note: There will be a lecture on the COLORADOS/2 conference. Roger
 MS> Sessions (yes, the IBM OO guru itself) "Persistence
 MS> Object Service for SOM:Many DataStores, One Object
 MS> Interface".

Unfortunately I won't be attending ColoradOS/2, even though I'd like to do
so.  I've got too much work to do and it is a fairly large chunk of money
as I'd have to pay for it out of my own funds.

 MS> PS: The 2 different stadards are related to 2
 MS> different ways of handling distributed objects. Assume
 MS> there is a central object server and many users want
 MS> to use objects the same time.
 MS> method 1 (OMG-Corba, proxies) : The Data is stored
 MS> only on the server. Clients are using proxies to
 MS> 'shadow' the class interface to their local machine.
 MS> The shadow just forward every call to the server.
 MS> (This is what distributed SOM is doing).

This is simpler, but has more opportunities for performance bottlenecks.

 MS> method 2 (OMG persistent framework). The object is duplicated to each
 MS> client. There are automatic update methods on the
 MS> server, so each client has up-to-date objects.

This is much more tricky -- storage consistency is hard to manage in such
an environment.

 MS> c) my comments: i would only buy a product of a
 MS> someone who is member of ODMG. I would NOT use any
 MS> RDBS for makeing object persistent. I would NOT use an
 MS> OODB which is just a wrapper for an RDBS (eg. the
 MS> RAIMA OO system is build this way).
 MS> members of ODMG: SunSoft, ObjectDesign, Ontos, O2
 MS> Tech, Versant, Objectivity,         HP, POET, Itasca,
 MS> Intellitic, DEC, Servio, TI

So far it seems that OODB systems and libraries cost a fortune. I can't
afford to use them on the projects I'm doing these days. Although I need
persistent storage for some information, it's nothing that can't be
provided with a few days extra coding on my own. Also the runtime fees that
some of these companies want are far too much -- it is cheaper to spend a
couple extra weeks writing code and not having to pay exorbinant runtime
fees of hundreds of dollars per copy of an application.

Moreover, after years of programming I have built up an inherent distrust
of code written by other people.  Often the interfaces are weird, the code
is buggy, and I end up wasting weeks figuring out how to use it only to
determine that it has some limitation that makes the library unworkable or
very painful to use.  I'd hope my code wouldn't be so horrible to other
programmers, but it's not clear to me that this would be the case given the
crappy (from my viewpoint,anyway) code written by other programmers who
supposedly have a lot more experience than I do.  Maybe sometimes
differences in style make one programmer's code look like garbage to some
other programmers even if it really isn't garbage?

 MS> I have buyed POET 2.1 personal edition for evaluation
 MS> usage mid juli and wrote some remarks / problems to
 MS> poet.
 MS> (eg. there is a poet.lib compiled for single threaded,
 MS> static bound CRT. thats a problem for me).

That's a problem for me, too.  I make extensive use of multithreading,often
having four or more threads running in a single process.  And in some cases
I have a variable number of threads depending on the number of resources
being used.  Anything that doesn't support multithreading is junk.

 MS> How to make something persisent:

 MS> 1st you write a .hcd file, containing c++ class headers.

 MS> eg:

 MS> persistent class person
 MS> {
 MS>  //...
 MS>  PTString name;
 MS>  PTDate   dateOfBirth;
 MS>  int      income;
 MS>  char     someThingElse;
 MS>  // ...
 MS> };

 MS> there is a precompiler which generates .hxx and .cxx
 MS> files out of this .hcd file. you use the .hxx files in
 MS> your app and you have to link the .cxx file to your
 MS> app.

That sounds like a so-so method of implementing persistance. Pecompilers
may not be intrinsically bad, but they could cause problems with a rapidly
evolving language such as C++ where it seems every new compiler release
implements several new language features.

Thanks for your thoughts on these issues.

--- Maximus/2 2.01wb