---

About Plug-ins

Structuring an application as a well-designed host framework and a set of plug-ins has many benefits to you as an application developer:

• You can implement and incorporate application features very quickly.

• Because plug-ins are separate modules with well-defined interfaces, you can quickly isolate and solve problems.

• You can create custom versions of an application without source code modifications.

• Third parties can develop additional features without any effort on the part of the original application developer.

• Because plug-ins are language independent, you can reuse legacy code.

End-users also benefit from using applications with a plug-in architecture:

• They can customize feature sets to particular workflows.

• They can disable unwanted features, potentially simplifying the application’s interface, reducing memory footprint, and improving performance.

If you are a host application developer who is designing a new plug-in model for your applications you should consider using the Core Foundation plug-in model for all but the simplest situations. Adopting the plug-in architecture can save both you and your plug-in developers a great deal of time and effort. Using plug-ins frees you from having to design, implement, and test a new plug-in model yourself. Because plug-ins is already documented, you won’t have to develop and publish documentation for an entire plug-in architecture, only the interfaces your host application supports. And finally, your plug-in developers won’t have to learn yet another plug-in model.

If you have a plug-in model in place, you may still want to consider converting to Core Foundation plug-ins simply because your plug-in developers need Carbonize their plug-ins if they want them to work on Mac OS X. If the conversion to plug-ins is a small enough task, it probably makes sense to have them convert at the same time. The level of difficulty involved in the conversion depends primarily on how close your existing model is to the plug-in model.

If you have an existing plug-in model that represents too great an investment to give up, you probably can (and should) make use of the more primitive code-loading features of bundles to add support for multiple binary formats. See Bundle Programming Guide if you aren’t familiar with Core Foundation bundles.

The Core Foundation concepts and API documented here are specific to Carbon 1.1 and later. Carbon 1.0, which was first shipped with Mac OS 9, included an early version of plug-ins, but that programming interface is now considered deprecated. Core Foundation 1.3 (released with Carbon 1.1) maintains basic compatibility with the previous plug-in model. If you have code written to the older API and you don’t want to re-write it for the new API, you will still have to modify the code slightly to compile against the new header file. There are many differences between the 1.0 and 1.1 plug-in APIs, but only one you must worry about if you want to keep using the 1.0 plug-in model—the use of UUIDs instead of unique strings to identify factories, types, interfaces and so on. Because Core Foundation uses opaque types, you can simply cast the type CFStringRef to CFUUIDRef and the functions will still work properly.

---