diff options
Diffstat (limited to 'TAO/docs/releasenotes/TODO.html')
-rw-r--r-- | TAO/docs/releasenotes/TODO.html | 796 |
1 files changed, 0 insertions, 796 deletions
diff --git a/TAO/docs/releasenotes/TODO.html b/TAO/docs/releasenotes/TODO.html deleted file mode 100644 index e3e58cb58c7..00000000000 --- a/TAO/docs/releasenotes/TODO.html +++ /dev/null @@ -1,796 +0,0 @@ -<HTML> -<HEAD> - <TITLE>TAO TODO List</TITLE> -</HEAD> - <BODY TEXT="#000000" BGCOLOR="#FFFFFF"> - <!-- $Id$ --> - <CENTER><HR></CENTER> - - <CENTER> - <H3>General TODO list for TAO</H3> - </CENTER> - - <P> - This document presents a general TODO list for TAO, - 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. - Hopefully as more people gets involved it will become more - organized. - </P> - <P> - Last Updated: $Date$ $Revision$ - </P> - - <CENTER><HR></CENTER> - - <CENTER> - <H4>Work in progress</H4> - </CENTER> - - <UL> - <LI>Support native C++ exceptions. - This entails several subtasks: - <UL> - <LI><P>Create exceptions with the right dynamic type on the - client side. - </P> - <P>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 >>= operator or using the - forthcoming <CODE>DynAny</CODE>. - </P> - <P>System exceptions are even easier, we always know how - to create them. - </P> - </LI> - - <LI>Add the _raise() method to the exceptions... - </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? - </LI> - - <LI>On the client side, after creating the exception with - the right dynamic type we must invoke - <CODE>_raise()</CODE> on it. - </LI> - - <LI>Support the alternative mapping with an environment - variable, but with a default value (that <B>must</B> be - obtained from TSS). - </LI> - - <LI>Support the standard mapping, without the environment - variable. - <BR>Add throw specs to the required methods (the stub, - skeleton, colocated classes, _tie classes, the - implementations in tests and examples, uf). - <BR>Should throw specs show up on the method - <EM>definition</EM>? - </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 comman before the TAO_ENV_ARG parameter. - </LI> - - <LI>In general we will need to complete and debug the - <CODE>TAO_TRY</CODE> macros; - accepting their limitations when dealing with the - alternative mapping, they are still useful; - but we need some macro to encapsulate a common use of - the CORBA::Environment argument: checking if it contains an - exception and then returning and more flexibility wrt the - argument name. - </LI> - </UL> - <BR>[STATUS] Carlos is working on this. - - <LI>Add compiled marshalling - <BR>[STATUS] Andy is working on this. - </LI> - - <LI>Implement the new DynAny types. - <BR>[STATUS] Jeff is working on this. - </LI> - - <LI>Implement an Implementation Repository for TAO. - <BR>[STATUS] Darrell is working on this. - </LI> - </UL> - - <CENTER><HR></CENTER> - - <CENTER> - <H4>Pending Tasks</H4> - </CENTER> - - <OL> - <LI><B>EC:</B> Automate EC multicast group usage. This probably - requires some kind of server that mantains the realtion - between event type/source and the mcast groups. - </LI> - - <LI><B>EC:</B> Improve configuration support in the EC, give an - example of a single threaded EC, support different dispatching - strategies, etc. - </LI> - - <LI>Add support for multiple Profiles in the ORB (completing the - IIOP 1.0 support) - </LI> - - <LI>Support IIOP 1.1 in the ORB - </LI> - - <LI>Support IIOP 1.2 in the ORB - </LI> - - <LI>Support GIOP 1.1 in the ORB (fragments) - </LI> - - <LI>Use the IIOP 1.1 profile info to pass QoS info and use it to - preserve end-to-end QoS. - </LI> - - <LI>Use active demuxing in the POA - </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). - </LI> - - <LI>Further optimize memory allocation by using a memory pool - for the incoming CDR stream. - </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). - </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 - </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() - </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. - </LI> - - <LI>IDL compiler front-end should be case insensitive (actually - it should flag identifiers that only differ by case as a - conflict). - </LI> - - <LI>The operation tables do not need to be statics, they could - be created on creation of the first servant of that type. - </LI> - - <LI>Add an option to the IDL-compiler (e.g. -rp) meaning - "generate relative include paths". - </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 - </LI> - - <LI>Support for unions with default cases (implicit or explicit) - in the IDL compiler is incomplete. - </LI> - - <LI>It seems that some memory is leaked from the ORB cached - connector. - </LI> - - <LI>Support for the fixed data type in the IDL compiler - </LI> - - <LI>CDR stream support for wchar is flaky or at least untested. - </LI> - - <LI>Add a corbafwd.h header file to eliminate the deep (and - recursive) header dependencies in TAO. - </LI> - - <LI>Add << and >> 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. - </LI> - - <LI>Add the <<= and >>= operators for - <CODE>CORBA::TypeCode</CODE> - </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> - </LI> - - <LI>Prepare the 1.0 release: - <UL> - <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> - </UL> - </LI> - - <LI>Support the Sun bootstrapping mechanism for the Naming - Service - </LI> - - <LI>Add a -ORBlogfile flag so we can set the ACE_ERROR and - ACE_DEBUG output destination in all TAO applications - </LI> - - <LI><B>EC:</B> Purify, purify, purify the EC - </LI> - - <LI><B>EC:</B> Quantify the EC. - </LI> - - <LI>Support several calls to ORB_init() on the same thread. - </LI> - - <LI><B>EC:</B> Call ORB_init() in the EC threads? - [The dispatching threads for Boeing] - </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.) - </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. - </LI> - - <LI><B>EC:</B> Correlation in the EC has a bug [?] - Build regression tests for the EC features (filtering, - correlation, timers, etc). - </LI> - - <LI><B>EC:</B> Build a COS Event Channel on top of the RTEC - Event Service. - </LI> - - <LI>Check what is failing in $TAO_ROOT/tests/CDR/tc. - </LI> - - <LI><B>EC:</B> Debug interval computation in Linux (and NT?) - </LI> - - <LI><B>EC:</B> Improve support for fragmentation and reassembly - in the multicast implementation of the EC. - </LI> - - <LI>Remove the uneeded methods from CORBA::Object - </LI> - - <LI>Study the CORBAlite spec and see how we could implement it - with TAO, considering dynamic and static configurations for - the full CORBA support - </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 <any> or <fixed> 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> - </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 - </LI> - <LI>UNIX socket support - </LI> - </UL> - Things that would be really hard: - <UL> - <LI>Dynamically load the support for costly features, as the - ImplRepo or Location Forwarding. - </LI> - <LI>Dynamically configure POA with or without support for - holding state. - </LI> - </UL> - </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. - </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. - </LI> - - <LI>The current scheme for the orbsvcs leaves the user without - control 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. - </LI> - - <LI><B>EC:</B> Cleanup the IDL structures for subscriptions, - publications, etc. (in the EC). - </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. - </LI> - <LI>If the interface repository ID is present then type - structural equivalence is not enough - </LI> - <LI>The spec (2.2 or 2.3?) will add a - <CODE>equivalent</CODE> method to check for structural - equivalence modulo aliases - </LI> - </UL> - </LI> - - - <LI><B>EC:</B> Use the Service_Configurator to dynamically load - the EC Module_Factory thus making it really configurable. - </LI> - - <LI>The current scheme for Typecode (keeping a CDR buffer with - their representation) is broken. - </LI> - - <LI>We must support a IFR. - </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. - </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. - </LI> - - <LI>The IDL compiler could generate a static method to access - the interface repository ID of a class. - </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. - </LI> - </OL> - - <CENTER> - <H4>Completed Tasks</H4> - </CENTER> - - <UL> - <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. - </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] - </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 TAO_Object_Field_T<T>, that - behaves like the _var classes, but extends them to provide - virtual methods to _upcast() and _downcast() to and from - CORBA_Object_ptr. - Similar methods were added to sequences of objects. - </LI> - - <LI>Add options to the IDL compiler to set the suffixes. - <BR>[DONE] Alex finished this. - </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. - </LI> - - <LI>The do_static_call() and do_dynamic_call() methods should - use an array of void* (in the first case static and generated - by the IDL compiler); - this will remove the problems with g++ and probably work - faster. - <BR>[DONE] - </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] - </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] - </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] - </LI> - - <LI>Add suspend and resume operations to the PushConsumerProxy - and PushSupplierProxy interfaces, following the Notification - Service spec. - <BR>[DONE] - </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] - </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). - </LI> - - <LI>Optimize Octet Sequences. - <BR>[DONE] - </LI> - - <LI>Obtain results for the EC_Multiple test. - <UL> - <LI>Latency seems OK. - </LI> - <LI> Overhead: need lower priority for scavenger thread. - </LI> - </UL> - </LI> - - <LI>Debug EC_Multiple. - </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 - </LI> - - <LI>Remove the SOLARIS2 macro from the TAO_IDL compilation. - <BR>[DONE] - </LI> - - <LI>Remove the preemption_prio message from Scheduling_Service. - </LI> - - <LI>The ORB core should be able to choose the right port for us - (in other words -ORBport 0) should work. - <BR>[DONE] - </LI> - - <LI>Client side optimization for Octet Sequences. - <BR>[DONE] - </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. - </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. - </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. - </LI> - - <LI>Support a chain of Message Blocks in Output CDRs and use - writev() to write them. - <BR>[DONE] - </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). - </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. - </LI> - - <LI>Show an example of the sequence<octet> and CDR streams. - <BR>[DONE] But the example could also include the marshalling of - plain C++ types. - <BR>[DONE too] - </LI> - - <LI>Test anys in the EC. - <BR>[DONE] Michael reported that they work OK on NT. - </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. - </LI> - - <LI>Unbind the EC and scheduling service from the Naming - Service. - <BR>[DONE] For the Event_Service and the examples. - </LI> - - <LI>Optimize oneways by not allocating the memory for the return - buffers. - <BR>[DONE] Added different Invocation classes for each case. - </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. - </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. - </LI> - - <LI>Fix the ACE_Thread_Condition madness. - <BR>[DONE] We changed ACE so ACE_SYNCH_CONDITION expands to - ACE_Condition_Thread_Mutex - </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] - </LI> - - <LI>Reference counting for Typecodes is completely broken. - <BR>[DONE] - </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) - </LI> - - <LI>The octet sequence optimization causes problems when Anys - get into the game. - <BR>[DONE] Seth reported that the problem was not real. - </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. - </LI> - - <LI>Improve error messages in the IDL compiler. - <BR>[DONE] At least the filename is correct now. - </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. - </LI> - - <LI>Prepare the 0.2 release: - <UL> - <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> - </UL> - <BR>[DONE] At last! - </LI> - - <LI>Move this list to the release notes. - </LI> - </UL> - -<HR> - -<P>Back to the TAO <A HREF="../index.html">documentation index</A>. <!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> |