Wednesday, December 18, 2002

Writable app wrapper There has been a thread on the Cocoa-Dev mailing list about where to store persistent, non-document, data for applications (i.e. user defaults, databases, caches, etc...). In particular, how to initialize this cache as the app starts up. Someone suggested that such writable data should be stored within the app wrapper. My response [rant?] follows (posted here because a couple of folks indicated that this should be archived in an easily accessible place): On Tuesday, Dec 17, 2002, at 16:11 US/Eastern, cocoa-dev-request@lists.apple.com wrote: Its not a big deal to update a pref file residing in the app folder from within your app. If a user moves the pref file out of the app folder, a new one will be created and the old prefs are lost, but that is no different for prefs in the pref folder. I have to chime in here... Do not ever, under any circumstances, for any reason, store prefs in the app folder. It is a bad, bad idea no matter what way you look at it. It is just lazy. There are places to store writable stuff that are well documented and well convered in this thread. In the app wrapper is NOT ONE OF THEM. It is wrong for so many reasons, let me list a few. Assuming writable prefs (or any other data) in the app wrapper, then: - backups have to back up the entire application. Inconvenient: I either have to know and back up just the apps that store data in their app wrapper OR I have to backup my entire Applications directory-- all umpteen hundreds of megabytes of data that otherwise very rarely changes and is often easier to just download off the net. - it hoses security; the app has to be writable by the user's account and, therefore, can be trivially corrupted or infected - it makes upgrading the app a pain in the ass; i can't just drag and drop to replace it. - it makes shipping upgrades a pain in the ass; the developer has to explicitly add support for the writable data in the app wrapper or risk losing customer data - makes it impossible to stick the app on read only media such as disk images, CDR, or network mount points. - it eliminates potential filesystem optimizations; a read-only filesystem can be assumed to be constant, thereby making operations such as memory mapping and operation caching potentially a bunch more expensive -- There is a disturbing trend in the mac community of requiring root privileges for installations when it is unnecessary, requiring reboots when it is unwarranted, requiring admin access just to run the app, and requiring write access to the app wrapper and other locations on disk that should not be. The justification is often "it is the user's computer they should do what they want". To put it bluntly: Bullhorkie. There is a very good reason to restrict access rights-- including administrative/root access and write access-- on the system as much as possible. It prevents nefarious code-- virii and crap code-- from doing any significant damage to the system. It also makes it possible to share applications across multiple users of the same machine while the user experience remains consistent-- when I use my sister's machine, I don't want to have to go hunting for freakin' TextEdit because she thought it should be called Pencil Power and should reside in Documents (if she wants to do that, fine, create a stupid alias!) Limiting the rights of the user increases security, decreases system fragility, decreases risks during updating, increases data reliability, increases convenience related to backing up data, and otherwise generally improves the user experience. Direct example: If you *follow* Apple's lead and put the prefs and other writable resources for an application in the defaults database and ~/Library/Application Support/ *as you should*, then an App like BackUp will *automatically* backup the volatile data related to the app in its default configuration-- the one that most users's will use AND it will do so without duplicating megabyte upon megabyte relatively static data [the app executable]. Continuing down this path of wanting to scribble everywhere because it is the Macintosh Way will lead to an Operating System that is no better than Windows; plenty of virii that cause piles of damage along with a system that has to be rebuilt every 3 months just to remain stable. That is not the Macintosh Way. b.bum --- Note that Radio-- the app used to create this weblog-- violates this principal quite thoroughly by storing the entire persistent store for one's weblog in the app directory (not really a true app wrapper). Worse, Radio hard codes a bunch of paths to the location of that directory in a fashion where it is a huge pain in the ass to move Radio. Radio also breaks if you have it on a removable volume-- say a volume named 'Data'-- and you happen to mount a volume of the same name prior to mounting the volume that Radio lives on. Renaming the volume that Radio lives on also breaks Radio. It is also a pain to backup-- I have to remember to add the entire folder to my BackUp profile and it eats a bunch of extra space with the App executable, DLLs and other resources that are largely static. Very annoying, but not a fatal flaw given the ease with which Radio allows one to build a 'blog. 4:29:08 PM

Bush rolls out missile defense system From CNN: WASHINGTON (CNN) -- President Bush announced plans Tuesday to deploy within two years the first phase of a limited system designed to protect the United States against a ballistic missile attack. And in other news... Garmin today announced a deal with Defense Department to ship 1,00,000 GPS units to all of the countries suspected of building or having built an intercontinental WMD delivery system. 11:16:46 AM