eventtypes a pub-sub mode. The code is available in a
  branch and it needs to be integrated in to the main-trunk. (ETA -
  2004/08)
  
StandardConfigurator interface. The servant for the
   StandardConfigurator interface should be implemented
  and activated by the servant for the component. DAnCE can extract
  the reference from the servant and use it to set attributes  (ETA -
  2004/08)
This includes making sure all components' appropriate ccm_passivate and ccm_remove operations are called when the ComponentServer is closing down.
(ETA - 2004/08)
 configuration_complete ()
   whose semantics are a bit unclear. We may have to use this
  to inform the components that the configuration is infact
  complete. (ETA - 2004/09)
 SessionComponent  interface called  ciao_preactivate ()
  and  ciao_postactivate ()  which has to be
 overridden by the executor code irrespective of whether the executor
 implements them or not. These were added to help components to know
 activation status of other components in the assembly. This could
 create problems for interoperability of the executor code. A better
 to way is to have the CIDL generate C++ code instead of executor IDL.
 The generated C++ code from the CIDL could provide default
 implementations which could be overridden by the executor code if so
 desired. This would make the executor code more portable. Obviously
 we also should retain executor IDL generation using some command line
 options. (ETA - 2004/09). 
.
Process component (which have 1:1 servant to OID mapping) might be useful too (no need to support PSS in this case?)
Persistent object references/IDs can be useful for statically configured DRE systems as they eliminate the initial handshakes in a multi-process system and enable each process to start up independently. (ETA - Not known)
generate_component_mpc.pl script should
      invoke the generate_export_file.pl automatically
      and created the necessary export files instead of only printing
      out the hints on how to do that. (ETA - Not known)
ComponentServer interface?
      (ETA - not known)
ComponentInstallation is the interface assembly mechanism used to interact with the deployment mechanism. We are free to implement the deployment mechanism (i.e., shipping of code to various locations of application domains) the way we like but the assembly mechanism depends on this interface to determine where to fetch a specific implementation.
One thing that we really need is an installation tool set which can be used to manage remote installation, by parsing various XML descriptors and either push or pull the right implmentation for a certain host in the list of hosts the component need to be installed. According to the CCM spec., ComponentInstallation interface implementation can retrieve a implementation (DLL) on an on-demand basis. Therefore, there is probably no need to push the appropriate DLL over right away when we feed some descriptors into the installation tool. The tool, however, should accurately extract the correct OS/compiler information and inform the ComponentInstallation impl which and where to fetch the right implmentation for the host it is running on. (ETA - not known)
ComponentInstallation can be done
      using a CORBAscript of some sort as this involve mostly
      registering and unregistering of locations of component
      implementations.
CIAO now provides more meaningful error message now.
A new target "CIAO_Core" is now available in ACE's top level Makefile.
  Some preliminary
      support using the environment
      variable CIAO_DEBUG_LEVEL has been added.