[Top][All Lists]

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

Re: preferences api

From: Richard Frith-Macdonald
Subject: Re: preferences api
Date: Mon, 16 Aug 2004 05:53:10 +0100

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

On 2004-08-16 11:15:27 +0800 Rogelio M.Serrano Jr. <address@hidden> wrote:

On 2004-08-14 11:48:21 +0800 Gregory John Casamento <address@hidden> wrote:
Yes, please see NSUserDefaults.
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]