ckd@cs.bu.edu (Christopher Davis) (01/10/91)
Anthony> == tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes:
Anthony> Is there some compelling reason why [saving preferences data
Anthony> within the program is] a bad thing to do?
Yes. Yes, yes, yes. Several times over.
1) Backup programs (like, say, DiskFit). Would you rather back up the
700K application, or the 30K preferences file?
2) Locking your applications to keep them more virus-safe...
3) RUNNING FROM A SERVER. This is a BIG one. Let's say we've got 5
Macs in the department, 5 copies of Word, but none of the machines
have hard disks yet. So we put Word on the AppleShare server... and
suddenly everyone else is stuck with MY preferences, since I'm the
only one who can write to the server volume...
Anthony> Nobody likes the way the System Folder gets cluttered with
Anthony> preferences files. Newer programs put prefs files in a single
Anthony> Preferences folder in the System Folder, but it's still hard to
Anthony> know which preferences files go with which program.
I dunno. "Word Settings" seems to indicate MS Word pretty easily... as
does something like "Canvas Prefs", "Stuffit Deluxe Preferences", or
what have you.
Anthony> A disadvantage would be that when a program is upgraded, a
Anthony> preference resource in the old program would have to be copied
Anthony> to the new one. But an installer program could easily do that.
Anthony> (Of course, nobody likes or trusts installer programs, either.
Anthony> :^)
What about folks who just drag the old one over, because they don't read
the README file?
--
[ Christopher Davis - <ckd@cs.bu.edu> - <..!bu.edu!cs.bu.edu!ckd> ]
A message destined for delivery in *your* domain is fair game for
anything you may want to do, up to and including translating the entire
message, header and all, into Swahili. -- chip@tct.uucp (Chip Salzenberg)anders@verity.com (Anders Wallgren) (01/10/91)
In article <1991Jan10.044428.6108@spool.cs.wisc.edu>, tonyrich@titanic (Anthony Rich) writes: >If a program allows user-preference settings to be saved, it usually >creates one or more "preferences" or "settings" files in the System Folder. >Why aren't the preferences stored in a resource within the program itself, >instead (say, in a PREF resource)? > >Is there some compelling reason why that would be a bad thing to do? > Yes. What if you want to put it on a file server and have multiple users use it simultaneously? Even though this could be done with some clever programming, the mac only supports one writer on a resource fork at once. Also, it may not be desirable to leave the application in a world-writable state all the time. anders
joseph@elbereth.rutgers.edu (Seymour Joseph) (01/11/91)
As I understand it, writing prefs to your own resource fork became a no-no with the introduction of AppleShare, read the tech notes on being appleshare compatible to get the details right from the horses mouth. I know two problems with an application writing prefs to its own resource fork: 1) The application must have write access to itself to save its prefs file. Often when an application is launched from a write protected floppy or AppleShare server, the application does not have write access to itself. An application can still save prefs if it puts them in the System:Preferences folder because a persons system disk is almost always write enabled. 2) If An application is designed to be AppleShare Multiple Launch compatible, it may have many people running it and trying to set preferences simultaneously. Writing those preference choices back to the application's resource fork just causes confusion. Chances are, a users settings will be changed before the next time they launch the application. If, on the other hand, you write each users prefs in their System:preferences folder, it will remain safe, and your application will act as expected the next time it is launched. There may also be other reasons for not doing this, but these are the two that immediately come to my mind. Seymour Joseph Rutgers Universtiy LCSR
teener@apple.com (Michael Teener) (01/26/91)
Another good reason to put prefs in files is that applications can then be kept in read-only media, such as CD ROM's and write-protected disks. But one of the *really* big reasons is that the modification date of of the application doesn't keep changing ... causing it to be copied by any useful incremental backup system. Right now I end up with over 2 Meg of the same damn files being sent to tape every night using Retrospect for this reason. (Of course, I could fix this by doing a more elaborate Retrospect script ... but that's more work than it's worth.) Fortunately, our group is using an 8mm Exabyte drive with 2 Gbytes available. ---- Michael Teener -- 408-974-3521 ---------------------------------+ ---- Internet teener@apple.com, AppleLink TEENER | ---- Apple may know my opinions, but *I* am responsible for them | ---------------------------------------------------------------------+ Transportation by Cheetah N9900U, a loyal beast for the past 7.5 years.
kscott@cgl.ucsf.edu (Kevin Scott) (01/28/91)
In article <1991Jan10.044428.6108@spool.cs.wisc.edu>, tonyrich@titanic (Anthony Rich) writes: >If a program allows user-preference settings to be saved, it usually >creates one or more "preferences" or "settings" files in the System >Folder. >Why aren't the preferences stored in a resource within the program itself, >instead (say, in a PREF resource)? jln@casbah.acns.nwu.edu (John Norstad) writes: 1) >One very big reason is virus protection on file servers. Applications >should never modify themselves so that server administrators can place >them in read-only folders on servers. If an application is stored in a >read-only folder on a server, it cannot get infected by network users. 2) For multiple users or even a single user with capricious tastes, a well behaved application will let you double click on the prefs to launch an application. My wife and I both share a machine, and even I have been known to keep two prefs for text (Palitino to mail letters, New York for readable onscreen text for my own notes).