Tumbled Logic

Aug 6 2009

Plug-Ins

This is one for the Mac OS X developers.

I’m developing a framework which, like most non-Apple frameworks on Mac OS X, will get shipped inside application bundles.

But, this framework will be plug-in-driven: as a database access layer, there will be drivers for talking to different database systems. At least one, for awkward complicated legal reasons, will mostly not be compiled into the framework itself, and instead be dynamically loaded. Now, I can deal with the case that plug-ins are to be shipped alongside the framework within the application bundle: this is easy enough. The only thing I need to be careful about is making sure that my framework doesn’t try to load plug-ins for the application which have nothing to do with it (a.k.a., “spooky action at a distance”), but that’s trivially accomplished through the magic of filename extensions.

I also want to allow for system-wide and user-wide plug-ins, though. Where should they live? On the one hand, mirroring the application bundle set-up is straightforward: I just read from Library/Application Support/{application name}/PlugIns/ or similar, but what if a user wants to install a plug-in for all applications using this framework (after all, that’s sort of the point)? The notion of using Application Support for per-framework resources grates upon my sensibilities, so I’m leaning towards Library/{framework}/PlugIns, but what do I call {framework}? The actual framework is called NGDatabase.framework, but that’s hardly an insanely friendly name for users to grasp when performing drag-and-drop installation, is it?

Perhaps I’m making too much of it, or over-thinking it, and Library/NGDatabase/PlugIns is fine?

Help me, vocal developers, you’re my only hope!

[Aside: I’d rather call my subdirectories Plug-Ins, but Apple made that decision for me a long time ago, and I’d rather be consistent with the OS than my own spelling choices].


blog comments powered by Disqus
Page 1 of 1