Requirements

• 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" model.
• 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 so on.
• 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 code level.
• 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 interface.
• 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.