Core Foundation Plug-in Services

Plug-in architectures are an attractive solution for developers seeking to build applications that are modular, customizable, and easily extensible. What began as a clever way to allow third parties to add features to an application without access to source code has, for many developers, evolved into a full-blown component architecture. Core Foundation Plug-in Services uses the basic code-loading facility of Core Foundation Bundle Services to provide a standard plug-in architecture for Mac OS applications. Although this chapter is addressed primarily to host application developers, plug-in developers also need to read it in order to fully understand and make use of the PlugIn Services model.

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

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

If you area 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 PlugIn Services architecture can save both you and your plug-in developers a great deal of time and effort. Using PlugIn Services frees you from having to design, implement, and test a new plug-in model yourself. Because PlugIn Services 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 PlugIn Services simply because your plug-in developers need to Carbonize their plug-ins if they want them to work on Mac OS X. If the conversion to PlugIn Services 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 PlugIn Services 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 Bundle Services' more primitive code-loading features to add support for multiple binary formats. See the chapter "Core Foundation Bundle Services" if you aren't familiar with Bundle Services.

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 PlugIn Services, 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 PlugIn Services 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. See the chapter "Core Foundation Utility Services" for information about UUIDs.

Header Files:

CFPlugin.h

Core Foundation Plug-in Services Concepts

Core Foundation Plug-in Services Tasks


© 1999 Apple Computer, Inc. (Last Updated 10 December 99)