Old c++ 0.5 spec:

class Port  { // empty handle base for exchanging functionality pointers }
class Services  { // fwk handle for component, full of C-isms. }
class Component { // setServices(s) }
class ComponentID  { // char* container }
class PortInfo  { // char* container, since rejected from spec }

Proposed extensions on the current classic::gov::cca to migrate to
an STL-based, memory safe, native c++ specification similar to
the sidl specification.

class ServicesSTL { // STL-ified Services, pure virtual }
class ComponentSTL { // STL-ified Services, pure virtual }
class ComponentID_Interface { // STL-ified Services, pure virtual }
class ConnectionID_Interface   { // STL-ified Services, pure virtual }
class TypeMap_interface { // STL-ified Services, pure virtual }
class Exception : public ::std::exception { // functions like sidl CCAException }
class TypeMismatchException : public Exception

typedef boost::shared_ptr < ConnectionID_Interface > ConnectionID_ptr;
typedef boost::shared_ptr < ComponentID_Interface > ComponentID_ptr;
typedef boost::shared_ptr<TypeMap_interface> TypeMap_ptr;


Why typedefs on these ID things and TypeMap?

a) ComponentID, ConnectionID, TypeMap are heavily shared items with
indefinite lifetimes. They are all created by framework implementation only
but may go out of scope at arbitrary times up to the component writer.
Thus we need a shared/ref-counted pointer model for them.

b) Why boost? It's (almost) a standard and it's designed for STL
compatibility from the ground up. For the proposed uses, it
does put least possible allocation burden (none*) on the component 
writer to call new, delete, addRef, delRef, or any non-standard 
casting operator.

(*) by "none" we mean that the component writer makes no calls to 
manage memory for the YYY_ptr unless they are storing one of these
framework objects in their private data. The burden then is, for 
example, after storing a TypeMap_ptr in a private data variable
the variable should be assigned to null (0) when the
containing object is destroyed.

c) Why not some other 'cca-blessed' c++ refcounting mechanism
(ala Parker's)? Well, we should be reusing existing standards
not inventing others (as babel has) which are redundant.

Why not typedefs for ServicesSTL, ComponentSTL, Port?

a) Port is impossible to properly manage with shared_ptr due to
likely premature destruction scenarios.

b) ServiceSTL and ComponentSTL have well delimited object life-cycles
in the specification, so they don't need ref counting at the framework
level.

c) Port, ServiceSTL, and ComponentSTL being typedef'd would place
an undue burden on the scientific component writer to understand the 
rather arcane template issues related to creating boost-wrapped objects.
Let's hide that inside the framework.