diff options
Diffstat (limited to 'CIAO/docs/TODO.html')
| -rw-r--r-- | CIAO/docs/TODO.html | 259 |
1 files changed, 0 insertions, 259 deletions
diff --git a/CIAO/docs/TODO.html b/CIAO/docs/TODO.html deleted file mode 100644 index 0b7ff8fd774..00000000000 --- a/CIAO/docs/TODO.html +++ /dev/null @@ -1,259 +0,0 @@ -<!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> |