diff options
Diffstat (limited to 'modules/CIAO/docs/TODO.html')
| -rw-r--r-- | modules/CIAO/docs/TODO.html | 259 |
1 files changed, 259 insertions, 0 deletions
diff --git a/modules/CIAO/docs/TODO.html b/modules/CIAO/docs/TODO.html new file mode 100644 index 00000000000..0b7ff8fd774 --- /dev/null +++ b/modules/CIAO/docs/TODO.html @@ -0,0 +1,259 @@ +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"><p> +<!-- $Id$ --> +<html> <head> +<title>Component-Integrated ACE ORB - TODO list</title> +</head> + +<body> +<h1>Component-Integrated ACE ORB (CIAO) - TODO list</h1> + +The following is a prioritized list of things (with the highest +priority items first) that the DOC group is working on. The expected +date of accomplishments are also added as ETA (expected time of +accomplishment) : + +<h3>Things to do:</h3> +<ul> + <li> Integrate TAO's real-time event channel within the + container. Components can use this feature to communicate using + <CODE>eventtype</CODE>s 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) + </li> <p> + + <li> Allow components (i.e., assemblies) to be connected using the + NameService (ETA - 2004/08) </li> <p> + + <li> Allow non-component enabled clients to access reference to a + component or an assembly using NameService (ETA - 2004/08) </li> <p> + + <li>Allowing components to set attributes, atleast attributes of + basic types. As a first step we need to implement the + <CODE>StandardConfigurator</CODE> interface. The servant for the + <CODE> StandardConfigurator</CODE> 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)</li><p> + +<li>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. <p> + + This includes making sure all components' appropriate + ccm_passivate and ccm_remove operations are called when the + ComponentServer is closing down.<p> (ETA - 2004/08) </li> + + <li> Migrate RT features from RTComponentServer to DAnCE + (ETA - 2004/10) </li> <p> + + <li> Static configuration of components using DAnCE (ETA - 2004/12) + </li> <p> + + <li>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)<p> + + <li>The naming convention used in <a + href="new_component.html">creating new component + instructions</a> and that used in <a + href="templates/">templates</a> do not match. (Files containing + glue code are named *_svnt.* and *GS.* respectively.) We need + to address that.(ETA - 07/2004) <p> </li> + + <li> Retire the old assembly and deployment framework (ETA - + 2004/10) </li> + + <li>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)<p> + + <li> 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) </li> <p> + + <li> 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 <CODE> configuration_complete () + </CODE> 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)</li><p> + + <li> We have now two proprietary methods in the <CODE> + SessionComponent </CODE> interface called <CODE> ciao_preactivate () + </CODE> and <CODE> ciao_postactivate () </CODE> 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). </li> <p> + +<li> 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) <li> <p>. + +<li>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)<p> + +<li>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)<p> + +<li>We should add support for the unclassified container and use the + property file of some sort to configure the empty container.<p> + + Process component (which have 1:1 servant to OID mapping) might + be useful too (no need to support PSS in this case?)<p> + + 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) <p> + + <li>The new <code>generate_component_mpc.pl</code> script should + invoke the <code>generate_export_file.pl</code> automatically + and created the necessary export files instead of only printing + out the hints on how to do that. (ETA - Not known)<p> + + <li>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). </li><p> + + <li><b>Container Factory</b>: 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 <code>ComponentServer</code> interface? + (ETA - not known)</li><p> + + <li><b>ComponentInstallation</b>: 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. <p> + + 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.<p> + + 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)<p> + <li><b>CIDL Compiler</b>: + 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. + + <li> This is a set of the to-do associated with the DAnCE implementation. + <p> + <ul> + <li>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.<p> + + <li>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.<p> + + <li>We need to work on the Resource Management process in + DAnCE. Right now this part of the DnC spec is omitted in our + implementation.<p> + + <li>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.<p> + </ul> + +</ul> + +<h3>Cool ideas</h3> +<ul> + <li>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.<p> + + <li>Management of <code>ComponentInstallation</code> can be done + using a CORBAscript of some sort as this involve mostly + registering and unregistering of locations of component + implementations.<p> +</ul> + +<h3>Finished Work</h3> +<ul> + <li>The exception returned from CIAO_Daemon when it fails to + locate a DLL is quite useless to say the least. It needs + fixing.<p> + + CIAO now provides more meaningful error message now.<p> + + <li>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.<p> + + A new target "CIAO_Core" is now available in ACE's top level + Makefile.<p> + + <li>We need better debug info and a way to control how different + level of debug info are generated in CIAO.<p> Some preliminary + support using the <a href="EnvVars.html">environment + variable</a> <code>CIAO_DEBUG_LEVEL</code> has been added.<P> + + <li>Miminal implementation of CIDL compiler.<p> + + <li>CCM core workspace now contains 3 different DLLs: + <UL> + <li>CCM_Client - Needed by CCM-awared client + <li>CCM_Container - Needed by executors and servers + <li>CCM_Server - Needed by servers and CIAO tools + </UL><p> + + <li>A SessionContainer implementation.<p> + +</ul> + +</body> </html> |