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

List:       kde
Subject:    KRegistry II
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1998-11-15 12:39:14
[Download RAW message or body]

 Hello, 
Perhaps I should rename the project, so people wouldn't think about the
Microsoft thing to much. Anyone any suggestions?

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.
- 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...

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.
Settings are only readable by the owner, ... 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 this design is fairly powerful and has
lots of potential... the combined thinking of the KDE Developers will make this
project even better than anyone could ever imagine...


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]