diff options
Diffstat (limited to 'modules/CIAO/docs/new_components.html')
-rw-r--r-- | modules/CIAO/docs/new_components.html | 129 |
1 files changed, 129 insertions, 0 deletions
diff --git a/modules/CIAO/docs/new_components.html b/modules/CIAO/docs/new_components.html new file mode 100644 index 00000000000..db10fca2103 --- /dev/null +++ b/modules/CIAO/docs/new_components.html @@ -0,0 +1,129 @@ +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> +<!-- $Id$ --> +<html> <head> +<title>Procedures to prepare a new component implementation</title> +</head> + +<body> +<h1>Preparing a new component implementation</h1> + +I am documenting the steps required to prepare a component implementation. +Personally, I prefer to set up a directory to contain only <b>one</b> +component implementation. I believe the procedures outlined below +will work if you have multiple component implementation in the same +IDL files. The purpose of this document is to record the procedures +and steps on how these files relate to each others and how they come +about during the development process.<p> + +Assuming we need to create a new component called +<code><b>Orc</b></code>. Below is the list of files you'll need to +deal with. Our goal is to greatly reduce the number of files you need +to deal with manually... + +<ol> + <li><font color="red"><code><b>Orc</b>.idl</code></font> - This is + the IDL file that contains the component and component home + definitions.<p> + + As you will eventually create 3 DLLs (or shared objects), you + will also need 3 sets of different export macros files as + following.<p> + + <li><code><b>Orc</b>_stub_export.h</code> - This file is generated + using the following command:<p> + + <code>generate_export_file.pl <b>ORC</b>_STUB > <b>Orc</b>_stub_export.h</code><p> + + This file makes macros like <code><b>ORC</b>_STUB_Export</code> + and friends available. They are usually controlled by + <code><b>ORC</b>_STUB_BUILD_DLL</code><p> + + <li><code><b>Orc</b>_svnt_export.h</code> - This file is generated + using the following command:<p> + + <code>generate_export_file.pl <b>ORC</b>_SVNT > <b>Orc</b>_svnt_export.h</code><p> + + This file makes macros like <code><b>ORC</b>_SVNT_Export</code> + and friends available. They are usually controlled by + <code><b>ORC</b>_SVNT_BUILD_DLL</code><p> + + <li><code><b>Orc</b>_exec_export.h</code> - This file is generated + using the following command:<p> + + <code>generate_export_file.pl <b>ORC</b>_EXEC > <b>Orc</b>_exec_export.h</code><p> + + This file makes macros like <code><b>ORC</b>_EXEC_Export</code> + and friends available. They are usually controlled by + <code><b>ORC</b>_EXEC_BUILD_DLL</code><p> + + <li><code><b>Orc</b>E.idl</code> - Component Executor equivalent + interface definitions. This file should be generated + automatically by the CIDL compiler as illustrated in this + <a href="com-impl.html">file</a> but we currently are still + working on the implementation of the CIDL compiler. Therefore, + you still need to create this file manually.<p> + + <li><font color="red"><code><b>Orc</b>EI.idl</code></font> - + Optional Component Executor implementation interface + definitions. Often time, when you implement a non-trivial + monolithic component implementation, you are required to define + the monolithic local executor interface which often inherits + from the component monolithic executor interface and all the + provided interfaces. The actually executor implementation will + inherit from this user defined interface instead of the default + executor mapping defined in <code><b>Orc</b>E.idl</code>. You + will need to do the same when you wish to support non-vanilla + component interface, such as + <code>Components::SessionComponent</code>, and/or + <code>Components::SessionSynchronization</code>.<p> + + Ideally, it would be perfect if we can auto-generate this + optional IDL file using CIDL compiler. However, I'm not sure + the plan CIDL language contains enough information that's + required to generate this file.<p> + + <li><font color="red"><code><b>Orc</b>_exec.*</code></font> - These + are files containing the actually component implementation that + you have to write manually. It, however, depends on the + equivalent executor IDL definition (that will be) generated by + the CIDL files.<p> + + <li><code><b>Orb</b>_svnt.*</code> - These are files containing the + servant glue code that bridge a container to the component + executor that you implement. Like the component executor + mapping IDL file, these files should be generated by the CIDL + compiler but are currently generated manually.<p> + + <li><code><b>Orc</b>.csd</code> - Component Softpkg Descriptor. We + need some kind of tool to generate this file automatically. It + is currently being generated manually, however.<p> + + + <li><code><b>Orc</b>.ssd</code> - Servant Softpkg Descriptor. This + is a CIAO extension descriptor file which uses the same softpkg + DTD as described in CCM spec. CIAO requires this file because + CIAO separates the executors into a completely separate DLL. + Like <code><b>Orc</b>.csd</code>, this file should be generated + automatically through some tool, but it is currently manually + crafted.<p> + + <li><code><b>Orc</b>.ccd</code> - CORBA Component Descriptor. This + file is currently being generated manually thou a template + should really be generated by CIAO's CIDL compiler.<p> + + <li><font color="red"><code><b>Orc</b>.mpc</code></font> - Makefile + Project Creator definition file. There is a perl script to + generate a minimal MPC definition at + <code>$(CIAO_ROOT)/bin/generate_component_mpc.pl</code> so + people can use it to implement the simplest component + implementation outlined in this file.<p> + +</ol> + + +<hr> +<address></address> +<!-- hhmts start --> +Last modified: Fri Mar 21 16:06:48 Central Standard Time 2003 +<!-- hhmts end --> +</body> </html> |