Re: "First Run" installation of Application support stuff?
Re: "First Run" installation of Application support stuff?
- Subject: Re: "First Run" installation of Application support stuff?
- From: Mike Ferris <email@hidden>
- Date: Mon, 16 Dec 2002 09:56:20 -0800
In my ~/Library/Application Support folder I have the following kinds
of stuff that seem OK
- Preference-type info that is too large to be in NSUserDefaults
(like PB workspace templates, LaunchBar configuration data, etc...)
- High score lists for games (although arguably this could be in
NSUserDefaults)
- License info (again, arguably could be in NSUserDefaults)
- AddressBook data (although I would rather recent Apple apps
allowed multiple "documents")
- Omniweb bookmarks, cookies, etc...
- Terminal startup file which I created
- Watson plugins (that were downloaded and installed separate
from Watson itself)
I would agree with all your points but the last. Plugins (being in
general executables) are by no means "support" data (as the rest of
your list describes). My personal preference would be to place them in
a separate PlugIns folder. An (acceptable) alternative used in some
cases by Apple and others is the */Library/Extensions folder, but this
is neither well documented, nor could I find any API supporting it. I
will also welcome consistent plugin (extension) naming, fixing the
singularity of the NSBundle's plugin method, support for plugin
enumerator, and plugin version...
I would like also to add that there is at least one additional
legitimate cases when plugins should be placed outside the application
bundle - when a software vendor has more then one application and
multiple applications use the same plugins. (The fact that Apple's
Installer is an excuse of an application is no excuse for forcing
everyone else to install even frameworks into the application bundle).
Defining a separate location for plug-ins is fine too. However, if
tons of apps start defining their own plug-in folders directly in
~/Library, it could get a bit messy... Watson's use of Application
Support is actually preferable in a lot of ways, especially, I think,
because downloading and installing and updating always happens
automatically (you just say OK when it asks if you want them).
For extensions, the best thing is for applications to define their own
app-specific extension for plug-ins (and then claim the extension as a
wrapper document type so they will be opaque and can have icons.)
I don't quite understand what you mean by the "singularity of the
NSBundle plugin method... I guess a couple dozen lines of code could
be saved with a higher level API for enumerating plug-ins, but really,
as long as you know where you're supposed to be looking, this is not a
lot of work with NSFileManager... There's also no formally established
way of doing versioning, but an app can certainly deal with plug-in
versioning and some lower-level facilities are available to make this
possible (such as Info.plists and the fact that a bundle's plist can be
queried prior to loading its code...)
Mike
_______________________________________________
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.