Re: Windows XP question (newbie)

From: Michele Andreoli (m.andreoli@tin.it)
Date: Fri Oct 25 2002 - 21:20:25 CEST


On Fri, Oct 25, 2002 at 06:56:02PM +0200, Dumas Patrice nicely wrote:

>
> > If we even accept TUCS as configuration API, how to agree on the names
> > of a key? IP? IPADDR? IP_ADDR? IP_ADDRESS?
>
> Why agree on a name of a key ? The name of a key is local to the application
> using it. I don't think that it is recommended to have applications share
> the same configuration information. Sharing runtime information is done by
> using the appropriate api.

? But more apps have to get values such IP, NETMASK etc from the
DB. So, we need of the key's name or, at least, a list of alias
for it.
I cannot follow you very well.

Maybe, you are thinking to substitute the name of the key with
a function name, like get_ip()?
But IP are only an example. You cannot project an API were every
future key has an own get_<>!
Surely, we will have a get_key(NAME_OF_KEY).

So, I, the developer, have to decide how to call the new key that
my apps are using, and export it to the rest of community, or no other
apps will use it or will interface with my app.

> Sometimes, yes, it could help having applications share the same information
> but I don't think there is a need of a central authority for that,
> developpers communication could suffice.

I disagree on that. This is utopic. This is /etc. IMHO.

>
> Only if there are keys which are to be used by any application, it would
> make sense to have a authority registering them. Maybe the lanana or
> something approaching.
>

Obviously. If you use in your apps a key that not need to be known
to other, you may not register it in the public name space.

Michele

-- 
"Physics is like sex: it may give some practical
results, but that's not why we do it"  (Richard Feynman)
---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.dk
For additional commands, e-mail: mulinux-help@sunsite.dk


This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:23 CET