[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde
Subject:    Virtual Config System
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1998-11-16 11:35:11
[Download RAW message or body]

<I am reposting this mail because I got some error messages from the
listserver after sending it the first time (my Reply-To: was wrong the
first time>

Hello,  


I have renamed the project to the "Virtual Config System". This name
better reflects the way it works...

While reading all your replies and comments, I saw that a lot of you
misunderstood me. The centralized registry is only the logical view the
user/programmer has on the configuration data. That doesn't mean all the
data has to be in one place!

My current design implementation works like a mixture of the OSI reference
model and the Linux Virtual Filesystem:

- Implement the registry libs in several layers, each layer abstracting more
  and doing more than the previous one <- OSI-like
- Mounting several registry-subtrees from other points.

So, if you want such an application to have a text based config file,
store it in your favorite rc file and mount that file! Than you would be able to
access the data like this: "/local/applications/appname/....". The "appname"
subdir would then be mounted from a textfile. The textfile would then be
monitored for changes done by hand.

If you would like your settings to be in the binary part, mount them
accordingly...

Migrating from text to binary or vice-versa is very simple... It is like
migrating a file from one NFS volume to another..

The registry will hold drivers for the several mount points. A textdriver
for regular KDE Config files, a LDAP driver, ...

What about the layers? At the bottom, you would have a simple layer
capable of a few low-level commands for updating (reading, setting, changing, 
....). The layer above would abstract location of the data (mounting, on a 
different computer)... the next layer would give you session management:
transactional access to the data. If you start KWord, you start a session 
with the registry. When ending KWord, you could choose to inject your 
changed settings in the registry! The idea is that you open a transaction 
when you start your application and that you commit when you end. In this 
way, guest accounts can make the changes they want, but those changes won't 
be visible in the next session. This choosing itself could be managed by a 
setting in the registry! So no need for a dialog box each time you close the 
application (which would be a very stupid thing). Look at the OSI model for 
more ideas concerning the layers.

A very rudimentary idea for the layers:

(top)
Application layer : show only the application part of the registry
....
Session Layer : transactional
....
Virtual Config System : mounting, ...
Drivers
<Security implemented through LDAP ACL, file permissions, ...>
(bottom)

Security is a major issue. Administrators would like to freeze some
settings. This should be  modeled above the current unix security system. 
For reasons of not duplicating user-databases.
Connections between registry servers should run above SSL (or SSH).

This design should please both text file fans as it should please binary
based or registry based fans! I personally think this design is fairly
powerful and has lots of potential... 


Bavo De Ridder


-- 
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"
PLEASE READ THE ARCHIVED MESSAGES AT http://lists.kde.org/ BEFORE POSTING
**********************************************************************
This list is from your pals at NetCentral <http://www.netcentral.net/>

[prev in list] [next in list] [prev in thread] [next in thread]