Re: preferences api

[Richard Frith-Macdonald]

On 16 Aug 2004, at 05:06, Rogelio M.Serrano Jr. wrote:

> On 2004-08-16 11:15:27 +0800 Rogelio M.Serrano Jr. 
> <rogelio@smsglobal.net> wrote:
>
> > On 2004-08-14 11:48:21 +0800 Gregory John Casamento 
> > <greg_casamento@yahoo.com> wrote:
> > > Rogelio,
> > > Yes, please see NSUserDefaults.
> > > GJC
> > Yes but this is only for users. What about for daemons? Can we use 
> > roots defaults to store all the configs for the whole machine? Right 
> > now im using a berkeley db database for all the daemons i wrote. It 
> > is one file located in /etc. Its a b-tree table and is too much for 
> > configurations but it offers me a standard way to save retreiving 
> > configs for all my programs without writing my own parser. And 
> > another program can easily change the config. And im not worried 
> > about mass destruction too.
>
> After going through apples docs on preferences and user defaults i 
> think there is a certain degree of freedom in how to implement the 
> whole config db issue. i prefer the extension of the mac os x style 
> user defaults into different fs domains instead of implementing 
> something like CFPreferences. user defaults are in 
> ~/Library/Preferences. other defaults could be in 
> /Library/Preferences/, /Network/Library/Preferences/,  
> /System/Library/Preferences/.
>
> Or am I missing something? Does NSUserDefaults already do that 
> depending on the parameters when creating the defaults entries?

No, there is a single user defaults database for each user.

> This still leaves my original question unanswered. How do system 
> daemons store and access their configs in GNUstep?

Exactly like any other program ...they use the user defaults database 
belonging to the user they are running as.
As a general principle of security, a daemon should not run as root 
unless it really needs to, but if it did, it would use the root user 
defaults database.

All the daemon (24*7 server) processes I write for the company I work 
for are expected (for security) to run as a well known user.  When we 
install our software, we set up a user account for it, and the 
processes check (on startup) that they are running as the expected 
user.

I don't think daemons are a problem for the current user defaults 
system at all ...

The one thing that the current system doesn't deal with is providing 
common values for *groups* of users.
In NeXTstep this was not an issue, as a NeXT box was very much a single 
user workstation.  In fact, for the vast majority of users, it's not an 
issue for GNUstep either.  If we *do* actually need to provide 
system-wide defaults we could easily implement them by having the 
defaults system load in a dictionary from a file in a standard location 
and place that in the search list before the registration defaults.  If 
we wanted system defaults which would override normal user defaults, we 
could do that with another dictionary in another file.

The only technical problem I see with the current implementation is 
that *all* defaults are held in memory ... which could get expensive on 
systems where applications use very large defaults databases.  A system 
which would split the defaults up, yet be able to load information on 
demand (and notice any updates efficiently) would be better.

At the moment, none of the above shortcomings are practical issues 
afaik (certainly not for me), so I'd say, "if it aint broke, don't fix 
it" ... unless it looks like it's interesting/fun for you to do.