I asked:
| What's wrong with the app writer using either the Java preferences API
| or NSUserDefaults directly? I don't see how you can significantly
| improve on
|
| Preferences.userRoot().get("FirstPlaceToLook", "homedirectory")
Brian Pinkerton wrote:
| Nothing. The question is what to do in the server.
>From what you've described so far, the answer seems to be, "nothing". All you've said is that you want Application X to have access to that application's preferences for User Y, who's running Application X. Using the Preferences API, that's exactly what you'll get. In the setup as you've described it, the server has no function: it does exactly the same thing the preferences API already does, and so is redundant if the preferences API is used.
| The server is
| running as root and needs access to users' preferences for the server
| domain, hopefully in a way that's clean and not kludgy.
Why does it need access to the preferences *files*? Why can't the application just *tell* the server what the preferences are, or what the application wants done, or whatever? (And what is the server doing that requires something so fraught with security problems as running as root?)
| As you suggest, apps (typically written in ObjC) can trivially
| communicate a user's wish to the server by updating preferences in
| response to some user action:
No, I didn't suggest that. I suggested that the applications use the preferences API to save preferences, that being the only thing you've said you wanted done. If I were to suggest a way for an application to communicate with a server, the preferences API wouldn't be the way. And this seems to be your problem: you're trying to use preferences for something that they weren't intended to be used for. Preferences are *not* a communications channel; they're a persistence mechanism, designed to allow a *single application* to store information in a particular place: the preferences folder. If you want the information stored somewhere else--in a server, for instance--the preferences API is the wrong choice. If you want the applications to communicate with a server, the preferences API is the wrong choice.
What you need is your own separate API:
ServerBasedPreferences.get("FirstPlaceToLook", "homedirectory")
where the ServerBasedPreferences class *by design* talks to the server. Do that, and your problems vanish. The server no longer needs access to the preferences files, because it's being told *directly* whatever it needs to know. It no longer needs access to the preferences files because ServerBasedPreferences can do whatever saving is necessary. It no longer needs access to the preferences files because ServerBasedPreferences can relay to the server whatever is needed when the application starts up. And for the application writer, things are no more complicated than before; he just needs to remember to use a different class name.
Glen Fisher
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
