CORBA based persistence engine

[Stefan Westerfeld <stefan space twc de>]

   Hi!

I have recently been working on a CORBA based persistence engine, which
will be used for KSynth. But as it is when you code, you begin finding
millions of applications for your code. This engine could at least solve
the whole GUI Builder debate for KDE, perhaps help KOffice development,
and perhaps more... ;)

Here's an introduction what this thing does, and what it can do for you.
Note that this is not KDE specific, but might be applied to Gnome and
other projects as well. It would be even better when things remain
compatible then ;)

[
In fact I send this announcement to the gnome-components-list/gnome-list
because I really hope that it will be a point where we can get more
compatible (as afaik both object models dont support persistence yet)!
]

What is persistence
===================

With persistent objects, you are able to tell your object "please - save
yourself to that file". Later, maybe the program has been terminated and
restarted, maybe the computer has been rebooted, maybe the file has been
send to your friend via email...

... but: you still can take the file and restore the object from it. It
will still be "the same" object, that means, if it was a 100 pixel*100 pixel
button with the label "Okay" before, you will have the same thing again
afterwards.

The thing starts becoming interesting, when you start to save collections
of objects. Imagine you have a whole dialog, with checkboxes, buttons,
a tabbed notebook and some pixmaps. You simply tell the dialog "save
yourself to that file", and later you are able to restore the dialog,
including all connections between the objects, all texts and pixmaps.

The same is true for documents, which have maybe embedded objects, maybe
pictures, maybe controls, whatever. You just throw them to a file, and
restore them when you need them again. Provided that on your target
machine the same installed components exist, you document will be
transportable.

More about dialogs & the GUI
============================
For dialogs, the interesting component is a dialog editor.
Without it, the thing would be boring: you write a program that sets up
the layout, connects the object, and sets all properties. You throw the
dialog - once created - to a file. Later, the program which needs
the dialog restores it.

But with a dialog editor, things look different. You click your dialog
together. Then, you save it to a file. Your application now restores
the dialog from the file every time it needs it.

When another user would like to change the look of your dialog, he can
do that even without modifying your source, or recompiling. He just loads
the dialog into an dialog editor (not even necessarily the same), and
changes everything he likes to change. He saves, and voila, the new dialog
is used by your application.

The thing starts becoming nice (but a little tricky), when not only the
dialogs of your application are managed that way, but - when its really
good - every control of your application. The user is now able to add
new menu items, change the look of your application, in certain limits
even the "workflow".

Toolkit issues
==============

Another important point are the toolkits. People sometimes find one
application totally useless for them, just because it's using "the wrong"
toolkit.

By creating object hierarchies, that contain well-defined GUI components,
such as buttons, checkboxes and tabbed notebooks, this problem could be
eliminated in the long run.

You just save your dialog (applicationg gui), which is currently using
toolkit A, and restore it using toolkit B. Voila, instant port, without
changing a single line of code ;)

Of course, this will become tricky, but for most cases, it should at least
work for large parts of the application (think of all houndrets of gimp
plugins, which hardly show more than one option dialog with some buttons).

About my current implementation
===============================

The current implementation uses CORBA, and as such be language independant.

It is currently based on mico as orb, since other orbs either are not free,
or don't know about any types and/or C++ bindings.

It provides an interface (Persist::PObject), which describes an persistent
object. When you are writing a new persistent object, you derive both,
interface and implementation. Then, you declare your attributes (such as
strings, structures, sequences of objects, objects, ...) in the IDL of
your object. When you are finished doing so, you implement your CORBA
object as you would do without persistence.

But additionally, you export your attributes in the constructor, declaring
whether they need to be saved & restored, and if they should be public
accessable (in an property editor of some GUI dialog editor or programming
environment).

Thats about all. (You need a factory, which can easily be declared via
macros).

The implementation can save and restore arbitary object collections, where
object attributes may contain references to other persistent objects.
Cyclic graphs can be processed as well (when A references B, and B refernces
C, and C references A).

Saving and restoring works with one "Persistent Manager" class.

For toolkit issues, it's recommended (in most cases I think necessary),
to save and restore the objects from/to the same code space using mico
shared libs.

This is also recommended for most other applications, since it improves
performance.

Status
======

Many things are not complete, and need more work. Especially slots and
signals are not there yet, but this would require some cooperation with
some object model (such as KOM or Baboon). I would prefer seeing a solution
there which unifies both approaches, since otherwise, there will not be
real interoperability between the various free components that will be
written. But this is IMHO one of the base requirements for a better
future of free software.

We need a common component model. The non free world has (been ;) standarized
on Active-X. We need to provide one credible alternative, not two or ten
or twenty.

Anyway, the core system is working fine, and happily restoring collections
of objects in the VFS example - so the thing with cyclic graphcs really
works ;)

If you are interested, please get it from http://space.twc.de/~stefan/kde

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
-- 
Send posts to:  kde@lists.netcentral.net
 Send all commands to:  kde-request@lists.netcentral.net
  Put your command in the SUBJECT of the message:
   "subscribe", "unsubscribe", "set digest on", or "set digest off"
**********************************************************************
This list is from your pals at NetCentral <http://www.netcentral.net/>

-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-