[K12OSN] Introduction and questions
mely at rogueriver.k12.or.us
Sun Dec 4 06:42:55 UTC 2005
Les Mikesell wrote:
> Storing user preferences in his own $HOME has been the unix way
> of doing things from the beginning of time. I can't imagine
> why you would want user-specific data anywhere else.
I wouldn't. On the other hand, what happens in the case of
Firefox(/mozilla/netscape/camino/etc) is that it touches a file called
"lock" in the active profile when it's loaded, and doesn't remove the
lockfile until the profile is unloaded - i.e.: the user quits firefox.
This to my mind is a bit more than is needed. A more-elegant solution
to me would be to have the lockfile created just before writing to
prefs.js or bookmarks or whatever, and then releasing the lock after
write. In the odd occurance that two users tried to write to the same
file at that particular millisecond, the second write would simply queue
for write. You'd have to write a catch for race conditions and loops,
but that wouldn't be difficult, and would make FF a lot easier to deploy
in such thin-client settings.
OpenOffice is a whole other ball of wax. My recollection about OOo
fighting with me was that it writes a ton of stuff to /tmp on load and
stores state information there while the program's being used. Again,
no reason to not check for and create instances.
Point is, I totally agree with storing configuration in $HOME, but state
info (including lockfiles) can and really ought to not prevent secondary
instances under the same credentials.
More information about the K12OSN