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/
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
