Component-Integrated ACE ORB (CIAO) - TODO list

Things to do:

• Integrate TAO's real-time event channel within the container. Components can use this feature to communicate using 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)
• Allow components (i.e., assemblies) to be connected using the NameService (ETA - 2004/08)
• Allow non-component enabled clients to access reference to a component or an assembly using NameService (ETA - 2004/08)
• Allowing components to set attributes, atleast attributes of basic types. As a first step we need to implement the 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)
• Now that we have supports for ccm_{activate,passivate,remove}, we need to rethink how a container manages the lifecycle of all the components/homes it hosts so all the servants related to a component get destroyed "properly". The aforementioned SessionComponent operations will also depend on the proper lifecycle management.

  This includes making sure all components' appropriate ccm_passivate and ccm_remove operations are called when the ComponentServer is closing down.

  (ETA - 2004/08)

• Migrate RT features from RTComponentServer to DAnCE (ETA - 2004/10)
• Static configuration of components using DAnCE (ETA - 2004/12)
• We need a set of tests to make sure most (and later all) of the data types are function correctly (in term of CIDL generated code). More importantly, we need to make sure all the component keywords are supported okay. (ETA - 2004/07)

• The naming convention used in creating new component instructions and that used in templates do not match. (Files containing glue code are named *_svnt.* and *GS.* respectively.) We need to address that.(ETA - 07/2004)

• Retire the old assembly and deployment framework (ETA - 2004/10)
• We need to review the implementation of servant glue code and container implementations to make sure that they are thread-safe, if the container calls for it. Currently, these states are changed only by the deployment framework which always runs in single thread, so it's not a serious problem. However, it's perfectly legal to dynamically configure connnections, which will be the case if we want to add new components or remove components from the assembly.(ETA - 2004/09)

• Add support for creating a thread pool within the the component server. We don't have support for this, which has made our users resort to spawning threads within the components, which breaks portability of the executor code. (ETA - 2004/09)
• At present components in an assembly have no way of knowing whether the assembly is complete or not. This becomes important when there are hierarchical assemblies, and the assembly at a higher level needs to pass on attrbute information to the assembly at a lower level. The spec talks about 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)
• Need to develop tools that would allow components to be added dynamically to an existing assembly and remove components dynamically from an existing assembly (ETA - 2004/12)

• .

• The CCM_Core libraries need to be refactored so regular CIAO users no longer need to link to CIAO_Server but to CIAO_Container library instead. Currently, the session container implementation is throwing exceptions from the deployment modules when it fails to install a home. But these feature should really be implmented in the Deployment::Container interface instead. (ETA - 2004/12)

• HomeRegistrar related files from the CCM_Core projects have been removed. We need to move them into a new directory when we get to a new HomeFinder/HomeRegistrar implementation. Notice that the deployment framework will need to use the HomeRegistrar interface to register components/homes. (ETA - 2004/12)

• We should add support for the unclassified container and use the property file of some sort to configure the empty container.

  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)

• The new 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)

• We need a ConfigValues parser for extracting common name-value info out of a ConfigValues sequence. This would be needed if components have to set complex user defined types as attributes. (ETA - not known).
• Container Factory: We need to provide a container factory interface to decide what kind of container we need to use. Hmm, isn't this the job of ComponentServer interface? (ETA - not known)
• ComponentInstallation: This is a simple interface that provides (UUID, Location) mappings. Both UUID and Location are of string type. Since ACE supports UUID implementation, we can probably use that to generate a UUID. Location should be URI, but let's just map that to locations in filesystem (pathnames) for now. So we will most likely need to provide more downloading mechanisms in the future, e.g., http, ftp, etc.

  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)

• CIDL Compiler: There are no immediate plans to support the part of CIDL corresponding to the OMG Persistent State Definition Langauge (PSDL). For an up-to-date status of the CIDL, please see $CIAO_ROOT/CCF/Documentation/TODO.
• This is a set of the to-do associated with the DAnCE implementation.
  • We need to put the ComponentServer layer back in. In the current implementation we use NodeApplication as both the Session Container and the ComponentServer. We need to seperate the two entities so we can hook any Container with the ComponentServer. This change is essential to the RT configuration and for the future of CIAO.

  • Bala added ciao_[pre|post]_activate to the Session Component to force the order of actions upon start-up, but this will not work with the new DnC framework. We need to change the DnC framework a bit to make this feature available again.

  • We need to work on the Resource Management process in DAnCE. Right now this part of the DnC spec is omitted in our implementation.

  • We need to work on the packaging process more so we can ship binaries around when the dll/so is not available in the local node.

Cool ideas

• Currently, developing a component will create 3 DLLs, one for the client side stuff, one for the servant glue code, and one for the executors. We need to figure out a way to automate these stuff. MPC is a good starting point to generate scripts to create project templates.

• Management of ComponentInstallation can be done using a CORBAscript of some sort as this involve mostly registering and unregistering of locations of component implementations.

Finished Work

• The exception returned from CIAO_Daemon when it fails to locate a DLL is quite useless to say the least. It needs fixing.

  CIAO now provides more meaningful error message now.

• We should create a new workspace/target in TAO such as CIAO_ONLY to simplify the process of using CIAO. Currently, you have to checkout the README file in CIAO_ROOT to figure out what TAO modules are required by CIAO.

  A new target "CIAO_Core" is now available in ACE's top level Makefile.

• We need better debug info and a way to control how different level of debug info are generated in CIAO.

  Some preliminary support using the environment variable CIAO_DEBUG_LEVEL has been added.

• Miminal implementation of CIDL compiler.

• CCM core workspace now contains 3 different DLLs:
  • CCM_Client - Needed by CCM-awared client
  • CCM_Container - Needed by executors and servers
  • CCM_Server - Needed by servers and CIAO tools

• A SessionContainer implementation.