Conclusions and a compact list of requirements for deconf-spec

[Jamie McCracken]

Philip Van Hoof wrote:

> My current idea for the deconf-desk service is to "only" cache the type
> signatures of the keys in the service's process address space. This can
> be written (with some bitwise operations and other cool techniques) in
> extremely small bitmaps and or lists. This can even be made mmap'able on
> some platforms. There's not going to be a possible way to tell me that
> it'll have a big impact on performance or memory of that service. It
> just wont. There's simply WAY to many ways to solve this. The only
> things needed to be cached in the service (for network transparency to
> be made possible) is things like the type information.
> 
> If the network admin overwrites the default "values", then of course
> also that is to be stored (and can also be made mmap'able since all that
> doesn't have to be humanly readable at all: this data isn't specified so
> it's an implementation detail). The whole idea of network transparency
> is overwriting (overloading) the default value, and force eliminating
> the custom user value via a central administrative location (over the
> wire) ... in a secure way (of course). 
> 
> And since also the type information is an administrative security
> consideration .. a network transparent administrable configuration
> environment is about overloading schema's. Nothing more, nothing less.
> 
> Because .. what does a schema contain?
> 
> 	- The default value
> 	- The type information
> 	- The description
> 
> 

I agree!

The problem is for an enterprise friendly system, an admin must be able 
to edit other peoples keys without having the respective schemae 
installed locally on the administrator's machine (so its not just about 
overloading values).

Ergo a system that enforces cleint side schemae only is fatally flawed.

Consider an admin using GConfEditor to enter values in a remote LDAP 
server -he may or may not have the schema locally so he will need to get 
from LDAP all the relevant schema data including type, validation and 
descriptions (as GConfEditor would need this). The server (service) 
would then have to enforce this validation to make sure erroneous values 
were not entered.

If some platforms are not interested in enterprise features (and I do 
respect that) then it would be better to make schemae optional in those 
cases (client side schema handling buys you nothing in thoses cases 
anyhow as the app will know what to expect)

-- 
Mr Jamie McCracken
http://www.advogato.org/person/jamiemcc/