Re: config library

><OBJECT NAME="object1">
>  <OBJECT NAME="object2">
>    <ATTRIBUTE NAME="attribute1">something</ATTRIBUTE>
>  </OBJECT>
>  <OBJECT NAME="object3">
>  </OBJECT>
>  <ATTRIBUTE NAME="attribute2">something else</ATTRIBUTE>
>  <ATTRIBUTE NAME="attribute3">more something</ATTRIBUTE>
><ATTRIBUTE NAME="attribute4">global something</ATTRIBUTE>

Or for another point:

<Object Name = "SimpleMTA">
		<ATTRIBUTE NAME = "SERVER"></attribute>

This gives a program all of the configuration it would ever need. 
Look at how much information is stored in this structure. Not 
only configuration information, but everything that a control
panel would ever need to know to configure it. 

That is a important feature, I think. 

If we were to use this system, It would allow for universal configuration,
based on the configuration value. 

Here is what I would propose:(In rough Pseudo code)

Structure config_handle
	- the section of the "Directory" that it wants to lock. 
	- Does it want to lock the global settings, or the users?
	- The current user, service, etc... Whatever distinguishes personilized
settings for the user. 

config_error_t config_lock(*config_handle)
	- Locks that object. 

config_erro_t set_setting(*config_handle, value)
	- Sets a value to set the configuration to. 

config_error_t get_config(*config_handle, value_to_look_up)
	- Returns a simple value. 

config_error_t get_XML_definition(*config_handle, char* XML_Structure); 
	- Gets the XML Strucutre (we probibly wouldent use a char... But whatever. 

config_error_t set_XML_definition(*config_handle, char* XML_Structure);
	- Sets the XML structure of an area. 

config_error_t commit_changes(*config_handle, value)
	- Commits mwhatever changes were pending. 

config_error_t release_lock_with_update(*config_handle)
	- you get the idea

config_error_t release_lock(*config_handle)

Points Raised by Tom's Definition.
	- I am not particularrly concerned about proccessed or services
	owned by the same user being seen. 
	- This is really the core elements. There would be procedures
		- To load from file, wipe the entire thing, etc. 
	- The type of the value being set is stored in the XML information. 
		That should make for a really easy way to pass information. 
	- Obviously, things like Stringlength are not written here. 

This really focuses on the XML details. The general config handle would have 
a path in it, which would identify it. (for instance,
the service would automaticlly figure out which file to look out (or what
LDAP directory to
search), weither there is a global default (in case there is no local
default), or weather the
global default should be returned, regardless if there is a local default. 

Most of this is just off the top of my head, doubtless, there are 20 or 30
major design 
problems in here... I just wanted to propose a change from business as general.

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