In K-3D, all plugin types currently fall into one of two distinct plugin "classes" (not to be confused with C++ classes): application and document. These two classes are defined in terms of the lifetimes and behavior of plugin instances.
Application plugins are not associated with any particular K-3D document - thus they are "global" in scope and lack serialization mechanisms, since they cannot be "saved" as part of any specific document. In general, application plugins are "strategy" objects used to implement behind-the-scenes behavior, and thus rarely visible to the end-user. Examples of application plugins include:
- User interface plugins (the desired user interface can be specified at startup using command-line arguments).
- Document importers and exporters (which work with documents, but aren't part of them).
- Plugins used to abstract-away platform-specific functionality (such as URL handlers).
Document plugins are associated with a specific K-3D document - they are the "objects" that users create to populate a document, including cameras, lights, geometry, etc. A document plugin instance is associated with a specific document at the time it is created, and that association never changes. Thus the lifetime of a document plugin is strongly tied to that of its document - when the document is deleted, so are all the associated document plugin instances. For this reason, a key feature of document plugins is serialization - document plugins include the features necessary to save and restore their data.