- 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. For example, TAO_IDL
currently doesn't generate the XXXConnections valuetype for a
multiple receptacle.
- A perl (or python, who cares) script to help generating the .csd
and .ssd files, and the UUIDs embedded in these files will be
very helpful. This script can also generate the entries for
both executor and servant libraries in the CIAO_Installation.ini
file.
- 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 suppor 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.
- CIAO Daemon should somehow be able to determine the kind of
component server required by an application. Currently, a CIAO
Daemon creates either a regular ComponentServer or a
RTComponentServer depending on how we start up the Daemon
process (based on a CIAO Daemon command line flag.) We should
be able to determine the requirement of the component server
from the ConfigValues of the create_component_server call.
This, of course, means that we need a better way to
configure the Daemon.
- Need to support linking of valuetype factory with the component
server via softpkg descriptor.
- 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.
- I have removed HomeRegistrar related files from the CCM_Core
projects. 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.
- 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.
We should also relocate many Deployment interface implementation
out of the CIAO_Server library. It doesn't make a lot of sense
to put them there.
- 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.
- Known issueThere is a strange bug in the implementation
of
::Components::ConnectionDescriptions
*CIAO_GLUE_HUDisplay::NavDisplay_Servant::get_connections
that is causing compilation errors on VC6 and I couldn't quite
figure out why. I commented out the offending line for now but
will need to fix it eventually.
- 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.
- 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.
- We need a ConfigValues parser for extracting common name-value
info out out a ConfigValues sequence.
- I am not sure what's the better way to pass the ConfigValues for
a ComponentServer from a ServerActivator. We can certainly
translate it into various command line options and a svc.conf
file. But it seems a much more elegant solution to try to
consolidate all these information in one single XML file for
ComponentServer. Passing ConfigValues to
Container's and CCMHome's is not a big
deal because the values are used within a process.
- Define RT policy extensions in Property file, Component
Assembly file.
- A simple generic server is now available in
CIAO/tools/Simple_Component_Server. It still needs a
ComponentServer interface to control the server and facilitate
component installation.
I find this tool somewhat
convenient to use for debugging component implementation as one
can run the simple server in a debugger easily. A real
component server, instead, requires much elaborate procedures to
debug, esp., that of an installed component. The simple
component server requires somewhat different meta-data to run.
We can probably create these simplified metadata easily from
idl/cidl compiler automatically. If this feature (easy
debugging) doesn't worth the effort, let's just put this into
the dumpster.
- We now always initialize a HomeRegistrar service in the
Simple_Component_Server. We should be able to configure the
component server to either initialize its own HomeRegistrar
interface, or to connect to another HomeRegistrar service thru a
proxy. This means that we should probably create a CIAO
standalone HomeRegistrar Service application.
- 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?
- AssemblyFactory and Assembly: These are part of the
deployment interfaces. They are currently implemented as a tool
$(CIAO_ROOT)/tools/Assembly_Deployer/Assembly_Manager.
A separate tool called Assembly_Deployer can be
used to interact with the Assembly_Manager to start
up and tear down application assemblies.
- 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.
- Component configuration using XML Property file:
Component property files (CPF files) specify the configuration
data for components/homes/servers. CPF can define data in
arbitrary CORBA data type, and specify the attribute name the
data should be applied to. There are two issues involved in
applying component property files (.cpf) to
components/homes/servers.
- Dynamic composition of configuration data: The data
specified in CPF files can either be
primitive types, such as
long,
short, or, Object, or composite
types, such as struct, sequence,
or, valuetype. By processing a CPF document,
an XML parser can build these data incrementally using
DynamicAny.
- Applying the configuration value: Once a
configuration tool builds the configuration data
dynamically, it will also know to which object
(component/home/others) and the attribute name the value
should apply to. This can be done either using DII, or by
using a special config interface generated by the CIF.
- 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.