These are the requirements of the plug-in interface for the Kinetica
project. We want to be able to package functional components up as reusable
"plug-ins", so that many different programs can use them, including
Bounce, MediaCalc, the MediaFlow authoring tool, as well as the many products
that it will produce.
- The plug-in interface should support "male" and "female"
plug-in surfaces in shared libraries. Some plug-in interfaces only publish
the "male" interface for plug-in authors to use, so you can only
plug into one proprietary program. We want to make it as easy to incorporate
plug-ins into your own programs, as it is to make your programs into plug-ins.
In the same way the "client/server" model can be generalized into
the more natural, less hierarchical "distributed computing" model,
the "plug-in" model should generalize into a more organic "plug-together"
- The plug-in interface should support multithreading. Compute intensive
signal processing tasks need to process asynchronously in the background.
Multithreading is crucial for distributed processing, network data streaming,
invoking and providing distributed services without blocking and deadlocking,
taking advantage of parallel processors, digital signal processors, and
- Plug-ins should be able to call each other. There needs to be a global
registry of services, like the Windows registry.
- It would be wonderful to have plug-in execution models: various kinds
of nestable plug-in containers that decide when to execute other plug-ins.
So we can support many different kinds of programming models, from batch
processing to real time; while loops, iterators, mappers, tree walkers,
deterministic sequences, time based triggers, event based simulations, musical
notations, pinball machines, stochastic models. They should plug together
and mix and match conveniently, and it should be as easy to develop new
plug-in execution modules as it is to develop new plug-in function modules.
- Plug-ins should have explicit control over the functionality they
export, and the host they're plugged into should have explicit control over
the functionality it exports to the plug-in.
- The plug-ins and hosts should not have to buy into each others object
systems or memory management strategies, and should not expose that level
of detail about themselves.
- We should implement adaptors for other popular plug-in formats, which
make it easy to incorporate pre-existing code, both at a binary and a source
- Plug-in adaptors can let us plug other male plug-ins into our own
female plug-in interfaces, as well as letting us encapsulate clusters of
our own plug-ins, as male plug-ins for other interfaces. Think of these
as inside and outside foriegn plug-in surfaces. Visual
Basic can do this for OLE Controls: you
can plug OLE controls into a Visual Basic program, and them compile that
program into another OLE control, that you can plug into other programs.
- Photoshop filters, importers, exporters.
This is an old plug-in interface, that's got a lot of baggage, but there
are many amazing plug-ins for it. Some of the fancier ones won't work in
anything but PhotoShop, and Adobe
is anything but encouraging people to clone the female part of their plug-in
- The C Standard Input/Output interface, stdio,
for programs that read and write from files. Make it possible to take a
program that expects command line arguments, and reads and writes from stdin,
stdout, stderr, and files, and map those files to stream inputs and outputs
of a plug-in.
- COM, the Common Object Model binary object
interface standard, from Microsoft. COM is a way
of defining interfaces that can be used from C++, C, and other languages.
COM specifies how objects interact within a single
application or between applications. COM has a specific
set of services that it provides:
- Interface Negotiation
- Memory Management
- Error and Status Reporting
- Interprocess Communication
- OLE, now known as ActiveX,
based on COM. This is Microsoft's constantly evolving
high level user interface component framework. It's pretty complicated,
but solves many of the same problems we need to solve. Most interestingly,
it has type libraries: metadata that describes
object properties, methods, and their signatures. These type libraries also
describe COM interfaces, and C++ data types. There
is a ITypeLibrary interfaces for dynamically querying these type libraries,
that programs like Visual Basic and the MSDEV
C++ compiler use to dynamically glue code together. Type libraries are
defined in the ODL and MIDL
interface definition languages.
- MacroMedia Director
plug-ins are now based on MOA. This is a great example
of a well thought out plug-in framework based on COM,
that's used across the whole MacroMedia Studio
product line. We should study it carefully, and see if we can license the
female parts from MacroMedia, or at least
get access to it through the M5 driver.
- mTropolis mFactory has a plug-in architecture
called "MOM", the mTropolis Object Model, based on COM.
- AutoDesk 3D Studio
Max is a very powerful 3D animation tool, that's totally plug-in oriented.
All of its many features are implemented as plug-ins. It's based on COM.
- Maxis created a version of SimCity 2000
that supports plug-in buildings and layers. They used COM
and are quite happy with it.
- QuickTime Components
might be useful, but probably not. The Component
Manager is a low level MacOS interface, that
has been ported to Windows for the purposes of QuickTime,
but there aren't alot of plug-ins for it, and it's not generally useful
outside of that domain.
- I suggest we base our low level plug-in interface on COM,
and some of the lower level parts of OLE, like the
type libraries, and the protocols for registering object servers with globally
unique IDs in the Registry. That will make it
easy to integrate with other plug-in interfaces based on COM,
like OLE, MOA, MOM,
ActiveMovie, and DirectX.
It seems to be a well designed "lowest COMmon
denominator" for plug-ins, and it runs on MacOS
and other platforms as well, and doesn't force you to use C++. Microsoft
is integrating COM into Java,
so we can work on COM right now, and hopefully later
on it will be easy to integrate into Java. In other
words, I don't suggest wasting any time on making Java
plug-ins using Sun's current cheezy Java native method interface, until
the fat lady's sung.