Re: config library. Was GNOME registry

[Rene Mayrhofer <rmayr vianova at>]

At 00:14 02.01.99 -0800, bob smith wrote:
>As to the corba idea, I think there should be corba wrappers to the
>library, but the main library should not contain it. The modules could
>contain corba
>as well.
I think so too. Using CORBA for saving to a flat file looks a little bit
like overkill, although I like the idea of CORBA for interfaces. Therefore
CORBA wrappers for a simple API would be perfect.

>The library should be as simple as posible but still look to the future.
>The API should stay the same but the modules can do just about whatever
>they want.
Agreed totally. Maybe we should provide an object-oriented API written in
ANSI C. I am thinking about something like GTK does (e.g. the signals). The
API should provide the possibility to get events delivered from it but
should not require the programmer to use it.
Does anybody have some experience with object-oriented programming with GTK
using a non-object-oriented language ?

>If we make the API too complex it will drive some programmers away.
>The idea is to make the library easier for the programmer to use then to
>code up there own. Throwing in alot of corba to programmers that have
>never seen it would be a "bad thing". 
Yes. This is an important point if we want programmers to use the library.
It must simplify things for them.

I think we should use a simple API, but we also should make the use of
CORBA possible. Maybe the API should be only C functions and when the
storage is something other than a local flat file model, then CORBA could
come into play for communication over the network or with a local LDAP
server. But when a local ASCII file (flat or XML) is to be used, there
should be no CORBA in between. That would make it too huge.

But we will have to take care of some points that CORBA would do for us:
> >Reasons: 
[snip] 
[snap]
> >2: Avoids race conditions (what if the d/b is partway through an update 
> >when an app reads it?) 
I am only thinking about multithreading.....
The library definitely has to be multithreaded with locking mechanisms
(maybe synchronously and asynchronously).
 
> >3: Provides an interface by which apps can be notified of changes to 
> >their config. Many apps won't _use_ this, but it should be there. 
There an object-oriented concept (maybe with signals) comes into mind.

> >4: If the apps can modify the d/b (they should be able to, but 
> >permissions will get tricky) then the well-debugged server can validate 
> >the update. This prevents buggy apps from trashing the registry. 
Transactions processing would be nice when used for many machines over the
network, but then we could use CORBA. For local files the API could only
provide access to "owned" areas of the registry. A program should "log on"
with its name and then get a handle to its own area in the storage. The
library will the only modify this area when called by the program.
[snip]
[snap] 
> >6: This way an app's config can be in local files, on a remote machine 
> >or calculated on-the-fly by a smart server somewhere on the network. 
> >It's all seamless and heterogeneous. 
The API can use CORBA if the storage is somewhere else.
[snip]

I think these problems can be solved without the need of CORBA.

Rene