diff options
Diffstat (limited to 'TAO/docs/releasenotes/TODO.html')
| -rw-r--r-- | TAO/docs/releasenotes/TODO.html | 136 |
1 files changed, 24 insertions, 112 deletions
diff --git a/TAO/docs/releasenotes/TODO.html b/TAO/docs/releasenotes/TODO.html index f74be91a90c..38dfb53d40c 100644 --- a/TAO/docs/releasenotes/TODO.html +++ b/TAO/docs/releasenotes/TODO.html @@ -48,14 +48,15 @@ <LI><P><B>EC:</B> Complete the implementation of the new EC, specially generate the strategies and changes required to support hard real-time behavior. - </P> - <P>The new EC does not update the dependencies in - the scheduling service. We should be able to strategize this - by the appropiate use of a <CODE>Filter_Builder</CODE> and - decorators for the regular filters. <BR>[ASSIGNED TO:] Carlos - <BR>[STATUS] All the pieces are in place, but I have to - continue debugging it. + </P> + </LI> + + <LI><P><B>EC:</B> We need to provide simple operations to update + the subscriptions of a consumer, as well as the publications + of a supplier, the current scheme (disconnecting and + connecting again) is inefficient. + <BR>[ASSIGNED TO:] Carlos </P> </LI> @@ -102,9 +103,6 @@ <LI><P>Add support for timeouts and protocol attributes to the ORB. <BR>[ASSIGNED TO:] Carlos - <BR>[STATUS] Support for the Policy objects is present, but - we haven't implemented any of the Policy objects and, of - course, we don't use them. </P> </LI> @@ -255,57 +253,6 @@ <H4>New features and Bug fixes</H4> <OL> - <LI><P><B>EC:</B>The <CODE>Priority_Dispatching</CODE> strategy - is incomplete. - <BR>[STATUS] The latest round of changes completed the - implementation, but more testing is required before dropping - this task - </P> - </LI> - <LI><P><B>EC:</B>Implement a dispatching strategy that uses the - current thread priority or ID to dispatch the event. This - will let us use multiple queues at different priorities but - without any scheduling service. - </P> - </LI> - <LI><P><B>EC:</B>Implement a null filter for consumers that - correctly matches the events, this can be used to do all the - filtering on the suppliers for applications that do not - require correlation. - </P> - </LI> - <LI><P><B>EC:</B>Several tests must be added to the event - channel testsuite, for example: - <UL> - <LI>A throughput test (move from - <CODE>EC_Throughtput</CODE>). - </LI> - <LI>A latency test (move from - <CODE>Event_Latency</CODE>) - </LI> - <LI>A connection time test - </LI> - <LI>A test to verify filtering and correlation - </LI> - <LI>A test to timeouts - </LI> - <LI>A priority inversion test - </LI> - <LI>A test to measure CPU scalability - </LI> - <LI>A stress test for gateways and observers - </LI> - </UL> - </P> - </LI> - <LI><P><B>EC:</B>Should we provide strategies to enforce the QoS - publications and subscriptions? This could require - collaborations with the scheduling service and possibly it - is only useful for debugging real-time applications, but it - certainly seems interesting. - </P> - </LI> - <LI><P><B>EC:</B> Optimize the updates to the SupplierFiltering module, specially when it is a singleton: currently it receives a <CODE>connected</CODE> call for each supplier, @@ -313,6 +260,12 @@ </P> </LI> + <LI><P><B>EC:</B> The supplier filters could depend on the QoS + data, as consumer filters do. We should provide a factory + for them too. + </P> + </LI> + <LI><P><B>EC:</B> We need some strategy in the EC to periodically flush out mibehaving suppliers and consumers. Examples of misbehavior include: suppliers flooding the EC; @@ -324,14 +277,9 @@ </P> </LI> - <LI><P><B>EC:</B>The observer in the <CODE>TAO_EC_Gateway</CODE> - class is not properly deactivated. - </P> - </LI> - <LI><P><B>EC:</B> Sometimes the Event Channel dead-locks during shutdown. According to Ulf Jährig - <jaehrig@desys.com>, an easy way to reproduce the + <jaehrig@desys.com>>;, an easy way to reproduce the problem is to run the EC_Throughput test under windows NT. <BR>[STATUS] The test in question works perfectly on NT; it looks like a race condition. Apparently this is only a @@ -647,6 +595,15 @@ class POA_Foo { services that we want. <P></LI> + <LI><P><B>EC:</B> Use the Service_Configurator to dynamically load + the EC Module_Factory thus making it really configurable. + The same feature is needed for the new + <CODE>EC_Factory</CODE> class. + <BR>[STATUS] Notice that this is fairly easy to implement, + there doesn't seem to be much demand for it. + </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 @@ -889,18 +846,6 @@ class POA_Foo { </P> </LI> - <LI><P>The <CODE>TAO_Object_Manager</CODE> class needs an - assigment operator from <CODE>T_var</CODE>. - Either change the class to have two arguments or - use the <CODE>T::_var_type</CODE> trait. - We also have to change the class generated by the IDL - compiler. - Similar changes maybe required for the - <CODE>TAO_String_Manager</CODE> and the - <CODE>TAO_Object_Field</CODE> classes. - </P> - </LI> - <HR> <!-- Things below this point are "big" tasks" that --> @@ -1111,39 +1056,6 @@ encapsulation format. <H3>Completed Tasks</H3> <OL> - <LI><P><B>EC:</B>The new implementation of the EC does not send - <CODE>disconnect</CODE> messages on shutdown, this has to be - implemented. - <BR>[DONE] - </P> - </LI> - <LI><P><B>EC:</B> Use the Service_Configurator to dynamically load - the EC Module_Factory thus making it really configurable. - The same feature is needed for the new - <CODE>EC_Factory</CODE> class. - <BR>[STATUS] Notice that this is fairly easy to implement, - there doesn't seem to be much demand for it. - <BR>[DONE] In the new EC it is possible to load the - strategy factory. - </P> - </LI> - - <LI><P><B>EC:</B> The supplier filters could depend on the QoS - data, as consumer filters do. We should provide a factory - for them too. - <BR>[DONE] - </P> - </LI> - - <LI><P><B>EC:</B> We need to provide simple operations to update - the subscriptions of a consumer, as well as the publications - of a supplier, the current scheme (disconnecting and - connecting again) is inefficient. - <BR>[ASSIGNED TO:] Carlos - <BR>[DONE] - </P> - </LI> - <LI><P><B>IDL Compiler:</B> Tom Ziomek <tomz@cc.comm.mot.com> reports that the IDL compiler does not verify that <CODE>oneway</CODE> operations |