[Detrius]

I'm interested in setting up an Application for which a third party could create plugin code to add or modify the abilities of the program. I know that the very core of this in Objective-C is to create a generalized protocol.

The question is the following: is there an easy way for my application to find gcc object files (.o) and dynamically load them, and incorporate them, which includes dynamically changing what is listed in a menu?

Or is this just a high end ability that has to be done by hand with bizarre document types that is generally only possible for large companies like Adobe?

[LordJavac]

I too am trying to do this, and what I've determined is that bundles are used for this functionality. You can put the object code in a bundle and load the bundle dynamically. Each bundle has a main class that can be accessed by anyone loading the bundle.

What I gather is that you'd have a protocol or base class in a framework that is in your main bundle and the plugin would be derived from that. Then you load the bundle and create an instance of its main class (or any class in the bundle?) and there you have your plugin.

[Rickster]

There are two basic ways to do it. One is to define a generic class for plugin makers to extend by subclassing, much like how the NSView architecture in Cocoa itself works. Another would be to define a formal protocol describing what methods plugin objects must implement. You can even do both. Either way, you don't necessarily need to include a framework in your app and define the class/protocol there; it can be defined in the app executable itself, and you could distribute just a header file to plugin developers.

There's another part to the task of creating a plugin architecture, though, and that's figuring out when to use the plugin objects. If you've got several subclasses of (for example) ImageExportFilter, you'll need to map human-readable names to them and include them in your Export panel. If you've got subclasses of SoundDecoder, you'll need to know what subclass to instantiate and use for a given sound format.

For examples of how a Cocoa-based plugin architecture could work, see Omni's open-source frameworks. The OmniFoundation framework defines a "bundle registry" system which can be used for automatically loading bundles and keeping track of loaded bundles. You can use it to help figure out when to use this or that plugin object. Other parts of our framworks show plugin architectures in action -- the OAPreferences subsystem in OmniAppKit is a plugin architecture for preference panes, and OWF and OmniHTML are full of modular systems.