Re: Brainstorm: Desktop


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

    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
    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 with
                       "unsubscribe" as the Subject.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]