More food for thoughts...
Im just about to finish a project where we created a configuration
service
to be used by application developers.
What we did was to create an adaptable/extensible design that include
the abilities
to handle most ways of accessing configuration information,
such as memory, files, database, corba, ldap,configuration servers,....
I'll try to outline the design here, it may look complicate but
the implementation ,
it turned out, was relativly simple.
Logical design:
----------------
The "service" are built around reading and writing NAME-TYPE-VALUE
triplets
For each combination of
ENV - NETWORKITEM - USER - FUNCTIONALITY - FUNC VERSION - FUNC
INSTANCE
a set of triplets are stored.
ENV - environment
could be a named desktop, development process
step (dev,test,training,production,..)
NETWORKITEM - piece of equipment executing functionality somewhere
in a network
usually a machine with an operating system,
but can also be a router JAVA BUTTON, etc.
USER - primary responsible for executing functionality
can either be a human being or background processes
related to security entities
FUNCTIONALITY
Software executing on a machine
could be application ,corba object, javabean,
module, com object, etc.
FUNC VERSION - version of functionality
different versions may need a new set of configuration
values
FUNC INSTANCE - identifier of functionalty
two or more instance may run on the same machineand
may need different config.
Technical Design:
--------------------
A "factory" creates a configuration "component" with following
interface:
value ReadInteger(name)
WriteInteger(name, value)
This component is used by the application developers
Now the config component uses a "strategy" object to actually read/write
the values.
The strategy object is responsible to look for information in certain
places
ex:
if value not found the look for default
look for values in following order: memory list,
local file, home dir file, corba, ldap, database etc.
Since it is the strategy object that determines "how" to look for
the values its
easy to create new ones with different search patterns/mechanisms.
The strategy object
can even call system owned strategy objects.
The strategy object uses one or more low-level driver object to
do its tasks
so what happens is really...
Strategy Config Driver
^
^
|
|
Read -> CONFIG -> Serial Strategy -> Memory driver
-> File driver
-> Corba driver
-> whatever
end of design:
By this design we hope to have a relativly "future proof" mechanism
of getting configuration information. Its also easy to centrally
or locally
administrate above design
Anything useful here ??
/Anders W. Tell
Financial Toolsmiths AB
Benjamin Saller Bender wrote:
On Tue, 7 Apr 1998, Derek Simkowiak wrote:
> Maybe the idea of a URL for the "Desktop" directory introduces too
> many complexities... or perhaps we need to limit what kind of information
> is stored in the "Desktop" directory... just trying to get back down to
> earth with this.
>I haven't really been following this thread, but it sounds like
what you want is an LDAP directory that can store user prefs so that the
same set up is available via the network, AND no pesky .rc files ;>--
To unsubscribe: mail gnome-list-request@gnome.org with
"unsubscribe" as the Subject.