summaryrefslogtreecommitdiff
path: root/TAO/docs/releasenotes/TODO.html
diff options
context:
space:
mode:
Diffstat (limited to 'TAO/docs/releasenotes/TODO.html')
-rw-r--r--TAO/docs/releasenotes/TODO.html1212
1 files changed, 0 insertions, 1212 deletions
diff --git a/TAO/docs/releasenotes/TODO.html b/TAO/docs/releasenotes/TODO.html
deleted file mode 100644
index e37268cb181..00000000000
--- a/TAO/docs/releasenotes/TODO.html
+++ /dev/null
@@ -1,1212 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
-<HEAD>
- <TITLE>TAO TO-DO List</TITLE>
-</HEAD>
- <BODY TEXT="#000000" BGCOLOR="#FFFFFF">
- <!-- $Id$ -->
- <CENTER><HR></CENTER>
-
- <CENTER>
- <H3>General TO-DO list for TAO</H3>
- </CENTER>
-
- <P>
- This document presents our TO-DO list for TAO.
- Currently, the list is not very well organized or prioritized.
- It started as a personal TODO list for Carlos, so it is biased
- towards the Event Service and related components.
- As more people get involved it will become more
- organized.
- </P>
- <P>
- Last Updated: $Date$ $Revision$
- </P>
-
- <HR>
- <P>
- <H3>Work in progress</H3>
- </P>
-
- <OL>
- <LI><P>Add compiled marshalling
- <BR>[STATUS] Andy is working on this.
- </P>
- </LI>
-
- <LI><P>Implement the new DynAny types.
- <BR>[STATUS] Jeff is working on this.
- </P>
- </LI>
-
- <LI><P>Implement an Implementation Repository for TAO.
- <BR>[STATUS] Darrell is working on this.
- </P>
- </LI>
-
- <LI><P>Support the thread pool reactor in the ORB.
- <BR>[STATUS] Nanbor is working on this.
- </P>
- </LI>
-
- </OL>
-
- <HR>
- <P>
- <H3>Pending Tasks</H3>
- </P>
-
- <H4>Performance optimizations</H4>
-
- <OL>
- <LI><P>Location forwarding should be strategized since some
- applications don't need this feature.
- </P>
- </LI>
-
- <LI>Further optimize the outgoing memory allocation by adding
- support for message blocks allocated from a pool (the
- Message_Block class itself not the Data_Block or the buffer it
- contains).
- <P></LI>
-
- <LI>Optimize twoways by delaying memory allocation for the
- incoming data buffer, thus improving interleaving between the
- client and server (the client does something useful before
- starting to wait for the server).
- <P></LI>
-
- <LI>The data blocks and their buffers could be allocated in a
- single operation, using the beginning of a buffer to contain
- the data block and the rest of it to contain the actual buffer
- <P></LI>
-
- <LI><P>Some applications cannot afford compiled marshaling for
- all the stubs and skeletons,
- the generated code size would be too big.
- Yet some operations could be critical and require code as
- efficient as possible;
- a <CODE>#pragma</CODE> can be added to give users
- fine-grained control over code generation.
- </P>
- </LI>
-
- <LI><P>For extremely low latency applications we could remove
- some fields from the IIOP protocol, for instance:
- <UL>
- <LI>The first four bytes are always 'GIOP'
- </LI>
- <LI>In homogeneous environments sending the byte order is a
- waste
- </LI>
- <LI>Fields like the <CODE>Principal</CODE>, the services
- context list, the versions can also be removed
- </LI>
- </UL>
- <BR>[STATUS] Most of this optimizations were implemented,
- and can be enabled using the <CODE>-ORBiioplite</CODE> command
- line option.
- </P>
- </LI>
-
- <LI><P>Once the memory for incoming data is taken from an
- allocator we can implement different approaches to manage
- that memory:
- <UL>
- <LI>The allocator is global, allowing applications to keep
- the incoming buffer even after the upcall has finished.
- </LI>
- <LI>The allocator is TSS, giving maximum performance for
- applications that do not wish to preserve the buffer
- after the upcall.
- </LI>
- <LI>The allocator is a TSS cache for a global memory pool,
- this tries to strike a balance, by practically eliminating
- the locking on each allocator/deallocation. Some strategy
- is required to return the memory to the global pool,
- consider, for example,
- an application that will always allocate memory from one
- thread and deallocate it in another thread.
- </LI>
- </UL>
- </P>
- </LI>
-
- <LI><P>Optimize marshaling for <CODE>TypeCode</CODE>, by not
- including the optional fields on the wire;
- this fields are useful (in some cases), so they should be
- present for the "on memory" representation.
- </P>
- </LI>
-
- <LI><P>In some cases it is possible to marshal a complete
- structure in a single operation to allow this the structure
- must have fixed size (in the CDR spec sense) and its memory
- layout must match the CDR layout.
- </P>
- </LI>
-
- <LI><P>If all the arguments to an operation are fixed size then
- the header can be sent before the rest of the data, if the
- data is big enoug this can represent a performance
- improvement (because we increase overlapping between client
- and server); further if the arguments also have the proper
- layout they can be sent without copying to a temporary
- buffer.
- </P>
- <P>If the arguments are not fixed size the header could be
- sent before, but two passes over the data will be required.
- </P>
- <LI>
- </OL>
-
- <H4>New features and Bug fixes</H4>
- <OL>
- <LI><B>EC:</B> Improve configuration support in the EC, give an
- example of a single threaded EC, support different dispatching
- strategies, etc.
- <P></LI>
-
- <LI><P>Support native C++ exceptions.
- This entails the following subtasks:<P>
- <OL>
- <LI>Create exceptions with the right dynamic type on the
- client side.
- For SII this should be simple:
- the stub give us a list of the
- possible user exceptions together with the factory methods
- to allocate an exception of each type;
- if the exception is not on that list we throw a
- <CODE>CORBA::UNKNOWN</CODE>.
- For DII we have to throw a
- <CODE>CORBA::UnknownUserException</CODE>;
- the user will receive the real exception inside an
- <CODE>Any</CODE> then and she will have to extract it
- either using the &gt&gt= operator or using the
- forthcoming <CODE>DynAny</CODE>.
- System exceptions are even easier, we always know how
- to create them.
- <BR>[STATUS] SII is working OK, we still need to complete
- the support for DII.
- <BR>[STATUS] The DII support was completed, but remains
- untested.
- <P></LI>
-
- <LI>Add the _raise() method to the exceptions.
- <BR>[DONE]
- <P></LI>
-
- <LI>On the server side: catch any CORBA exceptions thrown by
- the upcall, and then transform that into the
- proper <CODE>Reply</CODE> to the client side.
- In the case of another C++ exception should we do
- something?
- <BR>[DONE]
- <P></LI>
-
- <LI>On the client side, after creating the exception with
- the right dynamic type we must invoke
- <CODE>_raise()</CODE> on it.
- <BR>[DONE]
- <P></LI>
-
- <LI>Provide a TSS default value for the CORBA_Environment,
- all the methods in the ORB library should use this
- default.
- <BR>[DONE]
- <P></LI>
-
- <LI>The IDL compiler should be able to generate the
- alternative mapping, but with the TSS default for the env
- argument.
- <BR>[DONE]
- <P></LI>
-
- <LI>The IDL compiler should generate the standard mapping,
- without the environment argument.
- <P></LI>
-
- <LI>In general we will need to complete and debug the
- <CODE>TAO_TRY</CODE> macros;
- they have limitations when dealing with the
- alternative mapping, but are very useful.
- <BR>[STATUS] This seems to be OK now, the code seems to
- compile and work correctly now.
- <BR>[STATUS] We need a new macro (TAO_TRY_THROW) to use
- inside the TAO_TRY blocks, because TAO_THROW will not go
- into the TAO_CATCH blocks, even if the exceptions match.
- <P></LI>
-
- <LI>We need to test the ORB for resource leaking in the
- presence of exceptions.
- <P></LI>
-
- <LI>We <EM>could</EM> write portable server side code with
- any of the mappings above if we use a macro for the env
- argument, but the results are ugly:
- <PRE>
-// IDL
-interface Foo {
- void bar (in long x);
-};
-
-// C++
-class Foo {
- void bar (CORBA::Long x TAO_ENV_ARG)
- TAO_THROW_SPEC ((CORBA::SystemException));
-};
- </PRE>
- note the missing comma before the TAO_ENV_ARG parameter.
- <P></LI>
-
- </OL>
- <BR>[STATUS] The main task ahead is to generate the conforming
- mapping for the server side, i.e. remove the
- <CODE>CORBA::Environment</CODE> argument and generate the
- throw specs.
- We need to wait for the compiled marshaling support to
- implement this feature, otherwise the number of conflicts,
- visitors and factories will grow without limit.
- </P>
- </LI>
-
- <LI><P><B>EC:</B> Automate EC multicast group usage. This probably
- requires some kind of server that mantains the relation
- between event type/source and the mcast groups.
- <BR>[STATUS] The multicast map server was defined, an
- example implementation that hardcodes the port, and casts
- the event type into the mcast address was implemented.
- <BR>[STATUS] An advanced example that uses multiple mcast
- groups per process was developed; this example would be used
- To test the required features for general mcast support.
- <BR>[STATUS] The example is able to automatically join and
- leave multicast groups, as the consumer set on a local EC
- changes.
- The test has been constructed to minimize resources, it only
- uses one socket for outgoing multicast messages;
- currently it uses only one socket for each local group of
- multicast UDP addresses sharing the same port;
- eventually more sockets may be needed,
- as sockets have limits on the number of multicast groups
- they can join.
- </P>
- </LI>
-
- <LI><P><B>EC:</B>The <CODE>TAO_EC_Gateway_IIOP</CODE> can be
- required to subscribe for events by source, but the source
- can be local instead of remote.
- This is not a problem since the Event Channel supports
- multiple supplier IDs,
- but we could check the local publications and remove those
- events from the Gateway publication and subscription list.
- </P>
- </LI>
-
- <LI>Add support for multiple Profiles in the ORB (completing the
- IIOP 1.0 support)
- <P></LI>
-
- <LI>Support IIOP 1.1 in the ORB
- <P></LI>
-
- <LI>Support IIOP 1.2 in the ORB
- <P></LI>
-
- <LI>Support GIOP 1.1 in the ORB (fragments)
- <P></LI>
-
- <LI>Use the IIOP 1.1 profile info to pass QoS info and use it to
- preserve end-to-end QoS.
- <P></LI>
-
- <LI>The size of pre-allocated buffer for the outgoing CDR
- streams is defined at compilation time; but if we use an
- efficient enough allocator we could make its size configurable
- via the svc.conf file. In any case the *second* (and
- subsequent) buffers come out of the allocator, so their sizes
- could be configured in the already mentioned file.
- <BR>[NOTE] We have to be able to do this while minimizing the
- number of calls to ORB_Core_instance()
- <P></LI>
-
- <LI>The TypeCode internal (private) state needs locking, double
- checked locking is needed to avoid excessive overhead, there
- is potential for memory leaks if this locking is not used.
- <P></LI>
-
- <LI>IDL compiler front-end should be case insensitive,
- actually it should flag identifiers that only differ by case
- as a conflict and verify that all uses of an identifier have
- the same case.
- <P></LI>
-
- <LI>The operation tables do not need to be statics, they could
- be created on creation of the first servant of that type.
- <P></LI>
-
- <LI>Support for unions with default cases (implicit or explicit)
- in the IDL compiler is incomplete.
- <P></LI>
-
- <LI>It seems that some memory is leaked from the ORB cached
- connector.
- <P></LI>
-
- <LI>Support for the fixed data type in the IDL compiler
- <P></LI>
-
- <LI>CDR stream support for wchar is flaky or at least untested.
- <P></LI>
-
- <LI>Add a corbafwd.h header file to eliminate the deep (and
- recursive) header dependencies in TAO.
- <P></LI>
-
- <LI>Add &lt&lt and &gt&gt operators to the
- <CODE>CORBA::Request</CODE> class, to simplify DII invocations
- (this is an Orbix-sism).
- The IDL compiler has to generate them for the user defined
- types.
- <P></LI>
-
- <LI>Several helper structs for <CODE>Any</CODE> have to be
- added, mainly: <CODE>to_object</CODE>, <CODE>to_wchar</CODE>,
- <CODE>to_wstring</CODE> and their <CODE>from_</CODE>
- <BR>[STATUS] Jeff added several of them, I need to check what
- is missing.
- <P></LI>
-
- <LI><P>The IDL compiler could generate files with empty
- implementation classes, just to make the life of implementors
- a bit easier.</P>
- </LI>
-
- <LI>Prepare the 1.0 release:<P>
- <OL>
- <LI>Integrate the compiled marshalling approach.
- </LI>
- <LI>Verify the GPERF is working in all the relevant
- platforms.
- </LI>
- <LI>Integrate active demux of operations?
- </LI>
- </OL>
- <P></LI>
-
- <LI>Support the Sun bootstrapping mechanism for the Naming
- Service
- <P></LI>
-
- <LI>Add a -ORBlogfile flag so we can set the ACE_ERROR and
- ACE_DEBUG output destination in all TAO applications
- <P></LI>
-
- <LI><B>EC:</B> Purify, purify, purify the EC
- <P></LI>
-
- <LI><B>EC:</B> Quantify the EC.
- <P></LI>
-
- <LI>Support several calls to ORB_init() on the same thread.
- <P></LI>
-
- <LI><B>EC:</B> Call ORB_init() in the EC threads?
- [The dispatching threads for Boeing]
- <P></LI>
-
- <LI><B>EC:</B> Build an EC example that uses all the cool features
- (multiple ORBs on each process, collocated EC and Scheduling
- service, Naming, etc.)
- <P></LI>
-
- <LI><B>EC:</B> Extend the Concurrency Service (or create a new
- one) that allow us to have global "barriers" to synchronize EC
- startup/shutdown.
- <P></LI>
-
- <LI><B>EC:</B> Correlation in the EC has a bug [?]
- Build regression tests for the EC features (filtering,
- correlation, timers, etc).
- <P></LI>
-
- <LI><B>EC:</B> Build a COS Event Channel on top of the RTEC
- Event Service.
- <P></LI>
-
- <LI><B>EC:</B> Debug interval computation in Linux (and NT?)
- <P></LI>
-
- <LI><B>EC:</B> Improve support for fragmentation and reassembly
- in the multicast implementation of the EC.
- <P></LI>
-
- <LI><P>Remove the uneeded methods from CORBA::Object
- <BR>[STATUS] This task seems to be complete
- </P>
- </LI>
-
- <LI>The IDL compiler could generate a static method to access
- the interface repository ID of a class.
- <P></LI>
-
- <LI>The IDL compiler should support
- <CODE>#include "orb.idl"</CODE> properly.
- IMHO it should not
- add any <CODE>#include</CODE> to the generated code and the
- <CODE>orb.idl</CODE> file should contain all the declarations,
- except for the pseudo objects that are should be hardcoded
- into the compiler.
- <P></LI>
-
- <LI>The current scheme for the orbsvcs leaves the user without
- control over collocation of servants, we need to move to a scheme
- similar to the one in $ACE_ROOT/netsvcs.
- <BR>[STATUS] The user can control collocation, but we need a
- dynamic way to do it (or an example) that exploits the Service
- Configurator. We also may need to split the library.
- <P></LI>
-
- <LI><B>EC:</B> Use the Service_Configurator to dynamically load
- the EC Module_Factory thus making it really configurable.
- <P></LI>
-
- <LI><B>EC:</B> Cleanup the IDL structures for subscriptions,
- publications, etc. (in the EC).
- <BR>[STATUS] Part of this was completed. The Header and
- Payload of the events are clearly distinguished, now we need
- to use only the Header in the Publication and Subscription
- definitions.
- <P></LI>
-
- <LI>Resolve the Typecode::equal dilemma: is it structural or
- type equivalence? Or a mixin?
- <BR>[STATUS] The correct interpretation seems to be:
- <UL>
- <LI>If the interface repository ID is not present and/or the
- optional field name is not present then TypeCode::equal
- should just test for structural equivalence.
- <P></LI>
- <LI>If the interface repository ID is present then type
- structural equivalence is not enough
- <P></LI>
- <LI>The spec (2.2 or 2.3?) will add a
- <CODE>equivalent</CODE> method to check for structural
- equivalence modulo aliases
- <P></LI>
- </UL>
- <P></LI>
-
- <LI><P>The methods on the server side <B>must</B> have a throw
- spec, check CORBA 2.2, 20.35</P>
- </LI>
-
- <LI><P>According to Vinoski and Henning the
- <CODE>CORBA::Policy</CODE> objects are also locality
- constrained.
- I could not find a references in the spec.</P>
- </LI>
-
- <LI><P>Exercise the insertion and extraction operators for
- <CODE>Any</CODE> in the <CODE>Param_Test</CODE>,
- for example, provide a new <CODE>-i dii_any_op</CODE>
- testing mode.
- </P>
- </LI>
-
- <LI><P>Improve the connection recycling strategies, for
- instance,
- several strategies are possible: limit the maximum number of
- open sockets, probably with both HWM and LWM bounds,
- with different policies to choose the socket to close (LFU,
- MRU?);
- or maybe be more aggresive and recycle a socket once
- all the object references pointing to a server are closed.
- The later approach could be easily implemented if each
- IIOP_Object held a reference to the set of sockets opened to
- a certain TCP/IP address.
- </P>
- </LI>
-
- <LI><P>Test Any with variable sized types, such as structures
- that contain a string inside. Jeff reports that there is a
- problem when destroying Anys initialized with this types,
- even if the IDL compiler generated <<= operator is used.
- </P>
- </LI>
-
- <LI><P>Include a regression test to verify that
- <CODE>octet</CODE> is <B>not</B> a valid discriminator for
- unions
- </P>
- </LI>
-
- <LI><P>Verify that the typecode for unions use a
- <CODE>octet</CODE> with value <CODE>0</CODE> for the default
- discriminator
- </P>
- </LI>
-
- <LI><P>Add the <CODE>CORBA::TypeCode::_tc_Bounds</CODE> and the
- <CODE>CORBA::TypeCode::_tc_BadKind</CODE> type codes.
- Currently they are in the wrong namespace (just
- <CODE>CORBA::_tc_Bounds</CODE>).
- </P>
- </LI>
-
- <LI><P>Is the client side in TAO handling a
- <CODE>CloseConnection</CODE> GIOP message properly?
- </P>
- </LI>
-
- <LI><P>If the connection to the server cannot be established the
- right exception is <CODE>TRANSIENT</CODE>, not
- <CODE>COMM_FAILURE</CODE>; this and other exception
- inconsistencies have to be checked
- </P>
- </LI>
-
- <LI><P>The spec (CORBA 2.2, 20.17) defines accesor methods for the
- fields of a <CODE>SystemException</CODE>.
- </P>
- </LI>
-
- <LI><P>In some platforms it may be necessary to add an extra
- value to an enum to force it to be 32-bits wide.
- </P>
- </LI>
-
- <LI><P>The spec requires that strings as fields of structures be
- initialized to the empty (not the null) string.
- </P>
- </LI>
-
- <LI><P>The <CODE>SINGLE_THREAD_MODEL</CODE> for the POA requires
- that the execution for all request on that POA happen on the
- same thread.
- </P>
- </LI>
-
- <LI><P>The methods in <CODE>CORBA::TypeCode</CODE> should be
- <CODE>const</CODE>.
- </P>
- </LI>
-
- <LI><P>Some ORBs (Visibroker is one example) incorrectly send a
- SYSTEM_EXCEPTION status reply when they are actually
- throwing a user exception.
- TAO is not handling this condition gracefully (this is a
- critical problem), but further, it could be interesting to
- support a "compatibility with broken ORBs" mode,
- and possibly strategize it.
- <BR>[STATUS] The ORB will not crash if it receives that
- message. It will attempt to parse the exception as a
- UserException, even if SYSTEM_EXCEPTION status is returned;
- currently there is no strategy to control this.
- </P>
- </LI>
-
- <LI><P><CODE>$TAO_ROOT/orbsvcs/tests</CODE> may require the same
- hierarchy changes that were done in
- <CODE>$TAO_ROOT/tests</CODE>.
- </P>
- </LI>
-
- <LI><P>The <CODE>_duplicate()</CODE> and <CODE>_narrow()</CODE>
- functions can throw exceptions, yet our mapping does not
- contain an <CODE>CORBA::Environment</CODE> argument.
- A similar problem ocurs with
- <CODE>ORB::resolve_initial_references</CODE>, the ORB can
- throw the <CODE>InvalidName</CODE> exception.
- </P>
- </LI>
-
- <LI><P>Apparently the implementation for the leader-follower
- model on the client side has bug:
- it will add the current thread to the follower list every
- time it returns from waiting in the condition variable,
- assuming that it was signaled and removed every time.
- </P>
- </LI>
-
- <LI><P>By default TAO disables Nagle's algorithm, this should be
- an optional feature, otherwise TAO will perform poorly over
- WANs.
- </P>
- </LI>
-
- <!-- Things below this point are "big" tasks" that -->
- <!-- could require major work -->
-
- <LI><P>The ORB should support server side and client side
- interceptors</P>
- </LI>
-
- <LI><P>The ORB does not have an interface repository</P>
- </LI>
-
- <LI><P>Once the interface repository is in place we could add
- support for CORBA script
- </P>
- </LI>
-
- <LI>The current scheme for Typecode (keeping a CDR buffer with
- their representation) is broken; we should use classes for
- each variant of a TypeCode; but initialization would be
- complicated then.
- <P></LI>
-
- <LI><P>The CORBAlite RFP is very interesting IMHO we just need to
- remove features from TAO to make it a CORBAlite
- implementation. The problem is how to keep the full blown
- CORBA implementation also, this is an idea:
- Write the TAOlite version of a class (example TypeCode):</P>
-
- <PRE>
- class TAO_CORBAlite_TypeCode {
- // Just the CORBAlite methods are implemented.
- };
- </PRE>
-
- <P>Derive the full blown implementation:</P>
-
- <PRE>
- class TAO_CORBA_TypeCode : public TAO_CORBAlite_TypeCode {
- // Declare all the other methods.
- };
- </PRE>
-
- <P>create two namespaces:</P>
-
- <PRE>
- // in tao/CORBAlite.h
- class CORBA {
- tyedef TAO_CORBAlite_TypeCode TypeCode;
- };
-
- // in tao/CORBAfull.h
- class CORBA {
- typedef TAO_CORBAfull_TypeCode TypeCode;
- };
- </PRE>
-
- <P>then (at compile time) the users chooses between the CORBAlite
- or CORBAfull implementations:</P>
-
- <PRE>
- // In $TAO_ROOT/tao/corba.h
- #if USERS_WANTS_FAT_FREE_CORBA
- #include "tao/CORBAlite.h"
- #else
- #include "tao/CORBAfull.h"
- #endif
- </PRE>
-
- <P>We need to consider how to support even smaller profiles that
- the CORBAlite RFP, like removing <CODE>Any</CODE> or
- <CODE>fixed&lt&gt</CODE> support.
- We also need to come out with a scheme to support
- interpretive marshalling in the CORBAlite framework (where
- TypeCodes don't have enough methods as to traverse them).
- </P>
- <P></LI>
-
- <LI>Consider decompositions of the ORB that would allow
- dynamically linked plug-ins, examples of things that would be
- easy to implement as plugins:
- <UL>
- <LI>SSL support
- <P></LI>
- <LI>UNIX socket support
- <P></LI>
- </UL>
- Things that would be really hard:
- <UL>
- <LI>Dynamically load the support for costly features, as the
- ImplRepo or Location Forwarding.
- <P></LI>
- <LI>Dynamically configure POA with or without support for
- holding state.
- <P></LI>
- </UL>
- <P></LI>
-
- <LI>Currently the IDL compiler creates an operation table that
- includes all the base classes operations; this permits the
- generation of efficient code that does not rely in
- dynamic_cast or the _downcast() method for Servants (which
- compare strings, hence it is slow).
- It could be interesting to implement the alternative approach
- were the class only looks its own operations and then tries
- the parent. This will reduce code size, but will probably
- decrease performance.
- <P></LI>
-
- <LI>Server_Request objects in TAO are magical, the _duplicate()
- method returns 0 and release() does nothing.
- The problem starts because Server_Request is allocated from the
- stack (to speed up things), hence reference counting would be
- useless. Adding a clone() method will work better, but the
- Server_Request holds pointers to several positions in the CDR
- stream, we could clone the CDR stream, but a normal
- Server_Request does not own it.... In our opinion (Carlos and
- Irfan) we need not worry about this until we find a use case for
- it.
- <P></LI>
-
- <LI>
- The current implementation of collocation is optimal for
- hard-real-time
- applications, but in some cases it may be desirable to follow
- the normal execution path yet minize costs for collocated
- calls.
- An example would include an application that activates the
- objects on demand.
- It would be interesting to have a half-collocated stub
- implementation, that will marshall the request and then
- invokes the normal path on the "server" side, but without
- crossing the kernel boundary. Ideally even the serialization
- could be minimized or avoided.
- <P></LI>
-
- </OL>
-
-
-<HR><P>
- <H3>Completed Tasks</H3>
-
- <OL>
- <LI><P><B>EC:</B>The <CODE>TAO_EC_Gateway_IIOP</CODE> class
- receives events from a "remote" EC and pushes them on the
- local EC.
- The subscription and publication list for the Gateway are
- the disjunction of the local EC consumer subscriptions.
- Unfortunately this can result in multiple supplier_IDs for
- the Gateway, the current implementation is not prepared to
- handle this.
- The Gateway must keep a list of suppliers, each one with a
- different supplier id,
- when it receives a remote event it should push the event
- only to the right supplier.
- It must also keep another supplier used for the events that
- are of interest by their event type, regardless of their
- supplier ID.
- <BR>[DONE]
- </P>
- </LI>
-
- <LI><P><B>EC:</B>The Event Channel must be able to accept more
- than one supplier with a given supplier ID, or at least we
- should be able to configure the EC to work in such a mode.
- This is required for some applications that treat the
- supplier ID as a "supplier type".
- <BR>[DONE]
- </P>
- </LI>
-
- <LI><P><B>EC:</B>If a Supplier disconnects while it has
- consumers registered for it's Supplier_ID,
- the consumers are not connected again even if the supplier
- reconnects.
- <BR>[DONE]
- </P>
- </LI>
-
- <LI><P>Further optimize memory allocation by using a memory pool
- for the incoming CDR stream.
- <BR>[DONE] The pool is configurable for the users that may
- want to steal the CDR buffer.
- </P>
- </LI>
-
- <LI><P>The nested upcall support must be strategized,
- some applications don't need this feature,
- other applications are single threaded or use an
- ORB-per-thread concurrency policy,
- so using a full-blown leader follower in all cases can
- result in a significant slow down.
- It seems like the right way to
- strategize this by changing the Client_Connection_Handlers.
- <BR>[DONE] Irfan and Carlos are finished this task.
- </P>
- </LI>
-
- <LI><P>Use active demuxing in the POA to locate servants in
- constant time, as well as active demuxing
- in the skeletons to locate operations in constant time.
- <BR>[DONE] Irfan finished this task.
- </P>
- </LI>
-
- <LI><P>Sometimes the ORB picks up the wrong name on multi-homed
- hosts,
- the <CODE>ACE_INET_Addr</CODE> class uses
- <CODE>gethostbyaddr_r</CODE> to convert from the address into
- a hostname, but it only uses the first alias.
- <BR>[DONE] The current implementation tries to use the
- alias that more closely matches the address of the given
- host.
- </P>
- </LI>
-
- <LI><P>Many of the test programs in the
- <CODE>$TAO_ROOT/tests</CODE> hierarchy are actually sample
- programs or performance tests.
- </P>
- <P>We need to re-organize this hierarchy, following the ACE
- scheme:
- <UL>
- <LI><B>tests</B> for programs that do regression testing.
- </LI>
- <LI><B>examples</B> for programs that illustrate how to use
- TAO, a service or a component
- </LI>
- <LI><B>performace-tests</B> for programs that are used in
- performance measurements
- </LI>
- </UL>
- the same hierarchy may be needed in
- <CODE>$TAO_ROOT/orbsvcs</CODE>.
- <BR>[DONE] Doug did this changes already, minor revisions
- many be necessary, and orbsvcs is still pending.
- </P>
- </LI>
-
- <LI>Cleanup memory managment in some of the servers, for
- instance: Naming still believes that controlling the memory
- for a stub will control the servants, this is not true
- anymore.
- <BR>[DONE] Marina fixed the Naming Service, the other services
- are working OK also.
- <P></LI>
-
- <LI><P>The mapping for the CORBA <CODE>boolean</CODE> type does
- not require the <CODE>CORBA::TRUE</CODE> constant,
- but it never mentions the <CODE>CORBA::B_TRUE</CODE> constant
- either; in fact it recommends the usage of the literals
- <CODE>0</CODE> and <CODE>1</CODE>.
- We should move to use the <CODE>CORBA::TRUE</CODE> style,
- because other ORBs offer the same feature,
- but only use the literals,
- to show the "Right Way"[tm] of doing CORBA things.
- </P>
- <BR>[DONE] Irfan removed the <CODE>CORBA::B_TRUE</CODE> and
- <CODE>CORBA::B_FALSE</CODE> constants and replaced them with
- the compliant <CODE>0</CODE> and <CODE>1</CODE>
- </LI>
-
- <LI><P>Add an option to the IDL-compiler (e.g. -rp) meaning
- "generate relative include paths".
- <BR>[STATUS] Alex is working on this.
- <BR>[DONE]
- </P>
- </LI>
-
- <LI><P>Add the &lt&lt= and &gt&gt= operators for
- <CODE>CORBA::TypeCode</CODE>
- <BR>[DONE] Jeff added the operators</P>
- </LI>
-
- <LI>The IDL compiler should generate the code locally (not in
- the directory where the .idl resides) or at least give an
- option to do so
- <BR>[DONE] Alex completed this, he even added an option to
- select the output directory.
- <P></LI>
-
- <LI>Are nested upcalls in different concurrency models, like
- thread-per-connection working?
- <BR>[STATUS] Irfan reports that this works correctly with
- <CODE>thread-per-connection</CODE>
- <BR>[DONE] The <CODE>NestedUpcall/Reactor</CODE> test is
- giving the same results with either
- <CODE>thread-per-connection</CODE> or <CODE>reactive</CODE>
- strategies.
- <P></LI>
-
- <LI>Normalize the compiled marshalling interface: the IDL
- compiler is going to generate a different interface than the
- code I showed in the EC_Custom_Marshal example; we need to
- make all the code consistent so users have easy access to it.
- <BR>[DONE]
- <P></LI>
-
- <LI>Object references inside structures or sequences are not
- decoded properly, the problem starts because the interpreter
- expects a CORBA::Object_ptr, but the real type is a T_var;
- virtual inheritance adds the last ingredient to the poison.
- <BR>[STATUS] A possible solution is to use a T_manager_var that
- has two fields a Object_ptr and a T_ptr....
- <BR>[DONE] The solution was to use
- <CODE>TAO_Object_Field_T&lt;T&gt;</CODE>, that
- behaves like the _var classes, but extends them to provide
- virtual methods to <CODE>_upcast()</CODE> and
- <CODE>_downcast()</CODE> to and from
- <CODE>CORBA_Object_ptr</CODE>.
- Similar methods were added to sequences of objects.
- <P></LI>
-
- <LI>Add options to the IDL compiler to set the suffixes.
- <BR>[DONE] Alex finished this.
- <P></LI>
-
- <LI>Support for 64bit longs in the IDL compiler
- <BR>[DONE] They were supported already, but we had to test
- them, I added a test to Param_Test.
- <P></LI>
-
- <LI>The do_static_call() and do_dynamic_call() methods should
- use an array of <CODE>void*</CODE>
- (in the first case static and generated by the IDL compiler);
- this will remove the problems with g++ and probably work
- faster.
- <BR>[DONE]
- <P></LI>
-
- <LI>The IDL compiler gets confused with paths in NT, this may be
- due to my changes to report errors correctly (coryan).
- <BR>[STATUS] Creating a Win32 workspace to try it.
- <BR>[DONE]
- <P></LI>
-
- <LI>The current implementation of octet sequences based on
- message blocks has a few problems, it cannot marshall
- chains of message blocks properly.
- Notice that complete support for chains of message blocks will
- complicate the sequence of octets implementation (like
- operator[]) and will make others either hard or expensive
- (like get_buffer ()).
- <BR>[STATUS] It seems like the best tradeoff would be to
- support the chain during marshalling, but disable or give no
- warranties for operator[] and get_buffer().
- <BR>[DONE]
- <P></LI>
-
- <LI>Debug Memory Pools in the EC there seem to be a problem when
- sending multiple events in a row (a memory leak, limit or
- corruption).
- <BR>[DONE]
- <P></LI>
-
- <LI>Add suspend and resume operations to the PushConsumerProxy
- and PushSupplierProxy interfaces, following the Notification
- Service spec.
- <BR>[DONE]
- <P></LI>
-
- <LI>Optimize connection lookup in the client side, using "hints"
- from the previous lookup, or keeping smaller sets on each IIOP
- profile or a combination of both.
- <BR>[STATUS] Irfan is working on
- this.
- <BR>[DONE]
- <P></LI>
-
- <LI>Optimize the outgoing CDR streams by using TSS memory pools
- for both the data blocks and the buffers.
- <BR>[DONE] But we may consider strategizing the kind of allocator
- we use (like using a free list instead of a generic
- ACE_Malloc).
- <P></LI>
-
- <LI>Optimize Octet Sequences.
- <BR>[DONE]
- <P></LI>
-
- <LI>Obtain results for the EC_Multiple test.
- <UL>
- <LI>Latency seems OK.
- <P></LI>
- <LI> Overhead: need lower priority for scavenger thread.
- <P></LI>
- </UL>
- <P></LI>
-
- <LI>Debug EC_Multiple.
- <P></LI>
-
- <LI>Your next assignment: Regenerate all methods in
- _tao_collocated to avoid "inherit via dominance" warnings.
- <BR>[STATUS] The IDL compiler was modified to generate a
- suitable
- <CODE>#pragma</CODE> that removes the warning, it reenables
- the warning when leaving the file
- <P></LI>
-
- <LI>Remove the SOLARIS2 macro from the TAO_IDL compilation.
- <BR>[DONE]
- <P></LI>
-
- <LI>Remove the preemption_prio message from Scheduling_Service.
- <P></LI>
-
- <LI>The ORB core should be able to choose the right port for us
- (in other words -ORBport 0) should work.
- <BR>[DONE]
- <P></LI>
-
- <LI>Client side optimization for Octet Sequences.
- <BR>[DONE]
- <P></LI>
-
- <LI>Minimize memory allocation in TAO
- <BR>[STATUS] Down to 3 on the client side and 4 on the server
- side.
- <BR>[STATUS] For oneways it is down to 0 (for the common case)
- on the client side and 2 on the server side. For twoways it is
- 2 on both sides.
- <P></LI>
-
- <LI>Automate subscription and publication list generation in the
- EC_Gateway.
- [VERY important for Boeing]
- <BR>[STATUS] Completed and debugged, but the EC is still
- buggy.
- <P></LI>
-
- <LI>Debug EC shutdown and startup....
- [Specially startup for Boeign, but shutdown is important for
- Purify and Quantify]
- <BR>[STATUS] Shutdown is clean and startup of threads can be
- controlled by the user.
- <P></LI>
-
- <LI>Support a chain of Message Blocks in Output CDRs and use
- writev() to write them.
- <BR>[DONE]
- <P></LI>
-
- <LI>Memory managment in the demarshalling engine, it is not
- clear that the current scheme works in all cases (like
- sequences of unions of anys).
- We also need to fix sequences of object references: how does
- the demarshalling engine learn about the dynamic type of the
- objects?
- Closely related to this is the problem of memory alignment for
- different architectures, we need to develop strategies for each
- one (they should only be a few) and choose the right one.
- <BR>[STATUS] This seems to be working for most of the cases, the
- main idea is to delay demarshalling until enough information
- is available, for instance, when decoding an Any just a
- reference to the CDR stream is stored, decoding actually
- happens when the user invokes >>= on the any (at that point
- all the info is there).
- <P></LI>
-
- <LI>Add a new Profile type that includes the QoS info and using
- for end-to-end QoS preservation.
- [DEPRECATED] The IIOP 1.1 Profiles can handle that.
- <P></LI>
-
- <LI>Show an example of the
- <CODE>sequence&lt;octet&gt;</CODE> and CDR streams.
- <BR>[DONE] But the example could also include the marshalling of
- plain C++ types.
- <BR>[DONE too]
- <P></LI>
-
- <LI>Test anys in the EC.
- <BR>[DONE] Michael reported that they work OK on NT.
- <P></LI>
-
- <LI>UDP for event channel and Multicast support in the EC.
- <BR>[STATUS] Manual configuration using Suppliers and Consumers is
- possible, automation is under research.
- <P></LI>
-
- <LI>Unbind the EC and scheduling service from the Naming
- Service.
- <BR>[DONE] For the Event_Service and the examples.
- <P></LI>
-
- <LI>Optimize oneways by not allocating the memory for the return
- buffers.
- <BR>[DONE] Added different Invocation classes for each case.
- <P></LI>
-
- <LI>Fix the _non_existent call.
- <BR>[DONE] The client side semantics match the new clarifications
- of the C++ RTF, the server side is implemented by the IDL
- compiler, though t could be a good idea to put that in the
- POA.
- <P></LI>
-
- <LI>Simplify EC configuration, a Factory class must provide the
- Dispatching, Supplier, Correlation and any other Modules that
- are required.
- This is the right spot to add trivial Dispatching or
- Correlation Modules and to dynamically load and configure the
- EC.
- <BR>[DONE] A Factory class is used to create the modules, only the
- default factory is implemented so far.
- <P></LI>
-
- <LI>Fix the ACE_Thread_Condition madness.
- <BR>[DONE] We changed ACE so ACE_SYNCH_CONDITION expands to
- ACE_Condition_Thread_Mutex
- <P></LI>
-
- <LI>Reference counting should have locks, but we should remove
- all the QueryInterface madness to make that work. The policy
- for references in multiple threads is: the reference count
- must be >2 if that happens.
- <BR>[STATUS] The QueryInterface method (all the COM stuff for that
- matter) was removed...
- <BR>[DONE]
- <P></LI>
-
- <LI>Reference counting for Typecodes is completely broken.
- <BR>[DONE]
- <P></LI>
-
- <LI>Under g++(2.7.2) the use of multiple inheritance in IDL
- triggers some compiler bug, if the IDL explictly generated the
- copy constructor for the skeletons (the POA_ classes) the
- problem would go away.
- <BR>[DONE] Fixed, Seth is testing the fixes and will commit them
- soon (Tue Jul 21 14:24:56 CDT 1998)
- <P></LI>
-
- <LI>The octet sequence optimization causes problems when Anys
- get into the game.
- <BR>[DONE] Seth reported that the problem was not real.
- <P></LI>
-
- <LI>The DEEP_FREE method is also broken, sometimes we need to
- release the top-level memory, sometimes not.
- <BR>[DONE] We always release the memory in the Any, it was failing
- due to weird interactions between the Environment containing
- an exception and the Any that also did.
- <P></LI>
-
- <LI>Improve error messages in the IDL compiler.
- <BR>[DONE] At least the filename is correct now.
- <P></LI>
-
- <LI>Support for arrays in the IDL compiler is incomplete,
- specially anonymous arrays.
- <BR>[DONE] According to Andy this is properly supported by the IDL
- compiler now.
- <P></LI>
-
- <LI>Prepare the 0.2 release:<P>
- <OL>
- <LI>Execute all the tests in $TAO_ROOT/tests
- </LI>
- <LI>Run Param_Test (SII) and record what fails and what works.
- </LI>
- <LI>Run Param_test (DII) and record what fails and what works.
- </LI>
- <LI>Run Param_Test across Endian Borders.
- </LI>
- </OL>
- <BR>[DONE] At last!
- <P></LI>
-
- <LI>Move this list to the release notes.
- <P></LI>
- </OL>
-
-<HR>
-
-<P>Back to the TAO <A HREF="../index.html">documentation index</A>.&nbsp;<!--#include virtual="/~schmidt/cgi-sig.html" -->
-</BODY>
-</HTML>