I was happy when I heard of Symbian's ECOM API (see Forum Nokia) for component discovery and instantiation at the 2003 Symbian Exposium, because I always end up creating from scratch something with equivalent functionality for my own work. I believe the ECOM API takes us a step closer to getting COM-like component functionality on Symbian. Small, interchangeable COM modules are one of the (rare) ideas that have impressed me about Microsoft's system architecture.

Unfortunately, I found the ECOM API falls a bit short of giving me the kind of component framework I'd like to have. First of all, it seems to me that the idea of interface discovery is missing -- there is no root interface through which I can query a component for its capabilities. Secondly, I don't want to have to track the destructor key for an object. I'd like to create an object, be able to pass it around, and when I'm finished with it, ask the object to go away and it should take care of this on its own. Having to manage the destructor key makes it more difficult to share a component between parts of my code -- who takes care of destroying the object?

The ECOM examples distributed with the SDK's seem to view ECOM as merely a tool for DLL polymorphism. ECOM does help with this, but I believe it can do much more.

I would like to share a design idea and bit of code I have found useful several times over now. The idea is to be entirely ECOM compatible, but to add a couple of conventions which give ECOM the salient features of COM. The scheme is encapsulated in 2 mandatory interface definitions. Ideally, if we could all start using the same interfaces, we might end up with a small pool of re-usable components. I also mention 2 small optional pieces of code that make life easier.

The first mandatory interface is MUnknown which is intended to be the base interface of every interface exposed through this mechanism. Not surprisingly, MUnknown has a QueryInterfaceL method for asking what other interfaces the component supports. Interface ID's are 32 bits long, in keeping with ECOM's API's. MUnknown also has AddRef and Release methods for lifetime management. When you create a component or query for a new interface on it, the reference count is increased. When you are finished with an interface, you should call Release. Standard COM rules apply but note that you can also use Symbian tools like CleanupReleasePushL(*myUnknown) then CleanupStack::PopAndDestroy(myUnknown) to your advantage.

The second mandatory interface is MTracksOwnDestructorKey. This interface has a single method SetDestructorKey which we use to store the destructor key passed back from REComSession::CreateImplementationL. In the object's destructor, which it will take care of calling when its reference count goes to 0, it should pass the destructor key to REComSession::DestroyedImplementation as required by ECOM.

The first handy optional piece is a small static-link DLL which I've called ECOMPLUS. It has very little code, just a CreateImplementationL method which takes only a TUid aImplementationUid as in the REComSession version. There is no mention of the TUid& aDtorIDKey destructor key which appears in all the REComSession::CreateImplementationL methods, because the ECOMPLUS implementation uses ECOM to create the component, assumes what it gets back will implement MUnknown (as everything in our scheme should), and then calls QueryInterfaceL on that interface to get the MTracksOwnDestructorKey interface and set the destructor key. You don't need to use this method or the dll -- you could manually query for MTracksOwnDestructorKey and set the key yourself each time you created an instance if you wanted to, and indeed you might need to if you want to use some of the more advanced ECOM CreateImplementationL methods.

The second optional building block is a base class for a component which implements MUnknown and MTracksOwnDestructorKey. It stores its own destructor key and keeps a reference count so that when Release is called enough times to bring the reference count down to 0, the object deletes itself. Again, there's nothing stopping you from implementing your class from scratch, as long as your object implements MUnknown and MTracksOwnDestructorKey.

Note that the only mandatory requirements of the convention are that an object properly implement the MUnknown and the MTracksOwnDestructorKey interfaces and that it returns a pointer to an MUnknown (sub)interface on creation. In all aspects the component is a regular ECOM component and can be used as such.

Symbian lets us get away with being simple about threading and process issues, but there would be nothing stopping us from fleshing this convention out to a full DCOM-like cross-process or even remotely executable system. Throw in an IDispatch equivalent, and you've even got the tools to start writing automation components that could be invoked from java or a scripting language.

I hope others find this helpful and I welcome comments or suggestions.

ecomplus.zip