AAF and its use of COM
The Component Object Model (COM) is currently used at the top level
API for AAF SDK. it does not imply that the AAF toolkit is particularly
tied to Windows or the Microsoft Development Tools, COM in this instance
is simply a discipline for writing and maintaining re-usable code libraries.
The use of COM shows that the AAF Code and it's libraries and DLL's
or shared objects adhere to the principles of Interface Invariance and
provided the mechanisms for supporting a robust third party shared code
library.
On non-Windows platforms COM support is provided by our own portable
library - (on Windows the AAF DLL isn't registered with the Registry
and you don't use CoCreateInstance to create Objects).
Refer to the routines in the ref-impl/src/com-api/com-dll for the specifics
of the underlying ImplAAFRoot and AAFUnknown interfaces.
It might be interesting to note that the Architecture of the SDK is
such that a top level API based on COM is not the only alternative,
there is an extra layer of abstraction below the COM API where the meat
of the methods is implemented. This implementation layer could equally
well act as the foundation for a Java API.
The main characteristics of COM-style interfaces are:
- Invariance of Interface
- Encapsulation - hiding the implementation
- Support for QueryInterface dynamic casting (Unique Interface Identifiers)
- Built-in reference Counting for pointers to Objects
The first thing most people have done when building on top of the AAF
COM API is to add some kind of Reference counting and smart pointers.
See the new AxExamples or the EDL2AAF project.
Further reading
Essential COM, Don Box, Addison Wesley 1998
Inside COM, Dale Rogerson, Microsoft Press 1997
Helper Functions
The example program InfoDumper probably shows the best structure for
using the COM API, Generally it helps to have extra Template Classes
to simplify the reference counting, where InfoDumper makes use of IAAFSmartPointer
James Cain's EDL2AAF introduces his own glue class cUnknownPtr to achieve
the same goal.
Issues of navigation around interfaces...
One school of thought (currently implemented in AAF) is to use QueryInterface
exclusively to discover the inheritance hierarchy of a Class. Whilst
following the spirit of COM this can lead to a large number of QueryInterface
calls while you 'probe in the dark' trying to find what interfaces a
particular interface supports.
There is a suggestion that for a later version of the SDK that a new
interface be introduced that uses public Interface Inheritance as an
alternative to the current system where there is no predictable relation
between the different interfaces a particular object can have. In the
current scheme the only way to find if an object supports an interface
to call QueryInterface on it, even if you know from the implementation
that an IAAFSourceClip is also an IAAFComponent.
See [Rogerson] Chapter 8
|
|
- Press
- EBU Liaison
Upcoming Events:
AMWA Europe Mtg
2 December 2023
AmberFin
Basingstoke, UK
Conference Notes:
Site Requirements:
- Adobe Acrobat
- Microsoft Word
- MS Power Point
|
