Re: Fast User Switching in Panther...
Re: Fast User Switching in Panther...
- Subject: Re: Fast User Switching in Panther...
- From: Dave Thorup <email@hidden>
- Date: Tue, 05 Aug 2003 12:48:53 -0600
I believe the reason that you are getting so much negative response on this
is because your design is flawed, or most people on the list view your
design as flawed because you haven't explained it correctly.
On 8/5/03 9:52 AM, "Alec Carlson" <email@hidden> wrote:
>
1. The Mac is powered off
>
2. UserA powers the Mac up and logs into Panther
>
3. As part of the OS startup process, a background server application is
>
launched. It will be run in a process owned by UserA.
This, as others have stated, is not correct. If you have a "background
server application" that is launched during the "OS startup process" then it
will not be run in a process owned by UserA and it will take place as step
2, not step 3. This process will be owned by root unless you've taken
measures to make it run by another user.
If the process runs as a Login Item, then that is something different
entirely. (See Below)
>
4. UserB comes over and fast switches the Mac to his account. UserB starts
>
using the Mac.
>
5. Sometime in the future, the background application running in UserA's
>
context gets a timed event which causes it to want to look up something from
>
the users Preference file. It executes the following:
>
>
userPrefs = [[NSUserDefaults standardUserDefaults]
>
persistentDomainForName:@2com.company.prefs2]
>
>
The intent is to get the user defaults of the user currently using the Mac -
>
the person interacting with the GUI since his preferences are the important
>
ones. That would be UserB. However, since the background app is running in
>
UserA9s context, this call returns UserA9s preferences, not UserB9s. Since
>
UserA has 3left the building2, his prefs don9t really matter...
If the process was launched in the way you described above (it would be
running as root) then the call to NSUserDefaults would neither return the
defaults for UserA nor UserB.
>
Now, I could use the NSUserDefaults 3- (id) initWithUser2 method but that
>
begs the question of how does the background app figure out that UserB is
>
now in control of the Mac and not UserA ? In addition, It9s possible that
>
the background app running in UserA9s context does not have read access to
>
UserB9s preference files - that would be another problem (but I can get
>
around that one...)
You could do this, and the way that the background app knows that UserB is
making the request is because the app that UserB is using should send a
request to the background app that includes the name of the user making the
request. For example, UserB's app sends the following string as a request:
"request:doSomething;user=UserB"
Then the background app knows that UserB is sending the request. Also,
since the background app would be running as root then it would have the
ability to read both UserA and UserB's defaults.
So, the design that I (and probably many others) am proposing for your app
would be something like this:
1. The Mac is powered off
2. UserA powers the Mac up.
3. As part of the startup process your app is launched in the background and
is owned by root.
4. UserA logs into the machine after the startup process is completed.
5. When a user needs your background app to do something, the app that he's
using sends a request that includes the user name.
6. Your background app uses the user name in each request to read the
appropriate preferences and act accordingly.
If you are using a Login Item:
If this is the case then you have not described it adequately in your
previous posts. In this case, as others have described, only the user that
installs you app as a Login Item should have any interaction with it. If
UserB has not installed your app, then he should not be affected by it,
period.
____________________________________
Dave Thorup
Software Engineer
email@hidden
www.kuwan.net
Defaults Manager - The premier editor for Mac OS X's User Defaults /
Preferences database.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.