1 files changed, 231 insertions, 0 deletions
diff --git a/ACE/TAO/docs/rtcorba/issues.html b/ACE/TAO/docs/rtcorba/issues.html
new file mode 100644
index 00000000000..43c3e1979b0
--- /dev/null
+++ b/ACE/TAO/docs/rtcorba/issues.html
@@ -0,0 +1,231 @@
+<html>
+
+<!-- $Id$ -->
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<title>Implementation Issues and Known Bugs</title>
+<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
+</head>
+
+<body>
+
+<h3><a name="top">Known Issues and TO-DO Items</a></h3>
+<p>This page contains a list of known RTCORBA-related issues and to-do
+items. The list does not include any of the reports from the bug tracking
+system, so be sureto <a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">query
+Bugzilla</a> for RTCORBA entries. </p>
+<ol>
+  <li><a href="#7">Integrating protocol policies with the Pluggable Protocols framework</a></li>
+  <li><a href="#10">Integrating Implementation Repository with RTCORBA and PP</a></li>
+  <li><a href="#12">Priority Banded Connections interoperability issues</a></li>
+  <li><a href="#2">Removing dependencies on ORB debug output from RTCORBA tests</a></li>
+  <li><a href="#14">Adding RTCORBA examples</a></li>
+  <li><a href="#5">Improving management of Private Connections</a></li>
+  <li><a href="#6">Redesigning profile management to satisfy new requirements
+    and to provide full
+    support for location forwarding</a></li>
+  <li><a href="#11">Location forwarding with client-exposed policies</a></li>
+  <li><a href="#8">Moving FT endpoint selection into the endpoint selectors framework</a></li>
+  <li><a href="#3">Introducing guidelines for debug output in TAO</a><br>
+  </li>
+</ol>
+<hr>
+<h4><a name="7">Integrating protocol policies with the Pluggable Protocols
+framework</a></h4>
+<p><i>RTCORBA::ServerProtocolPolicy</i> and <i>RTCORBA::ClientProtocolPolicy</i>
+allow
+application developers to select and configure ORB communication protocols, and
+to specify preferred order of their use. This functionality has been implemented
+in TAO, but is only available with RTCORBA. Since protocol management
+is of interest to a large chunk of TAO users (many of whom do not need RTCORBA
+otherwise),
+we should make protocol policies available even when RTCORBA is not used, better
+integrate them with the Pluggable Protocols framework, and provide a number of
+other enhancements.</p>
+<ol>
+  <li>Integrate protocol policies with PP framework. Make concrete <i> Protocol_Factories</i>
+responsible for creating corresponding <i>ProtocolProperties</i> with default and user-specified
+values (rather than having the knowledge about concrete <i>ProtocolProperties </i>embedded in the ORB).
+    This will enable the protocol policies to be used to
+configure any pluggable protocols without having to modify the ORB code for
+each protocol.<br>
+  </li>
+  <li>Make protocol policies available even when RTCORBA is not used. Once
+this is done, remove (or deprecate) <i>-ORBSndSock</i>, <i>-ORBRcvSock</i>,
+and <i>-ORBNodelay</i> ORB options.<br>
+  </li>
+  <li>Add support for <i>TCPProtocolProperties::dont_route</i>
+    in IIOP.<br> </li>
+  <li>Add support for protocol properties configuration in SHMIOP. (SHMIOP
+    properties are defined in <i>RTCORBA::SharedMemoryProtocolProperties</i>, but
+    are currently not supported in the protocol implementation.)</li>
+</ol>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+<h4><a name="10">Integrating Implementation Repository with RTCORBA and PP</a></h4>
+<p>Current version of Implementation Repository does not work properly with
+RTCORBA or Pluggable Protocols because it does not handle multiple endpoints for
+one server. Once RTCORBA implementation is complete, we should look into
+redesign of Implementation Repository.</p>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+<h4><a name="12">Priority Banded Connections interoperability issues</a></h4>
+<p>
+
+Section 4.12.2 (Binding of Priority Banded Connection) of the RT-CORBA
+spec talks about the <CODE>_bind_priority_band</CODE> implicit
+operation.  Clearly, this operation is not completely defined and
+neither is the reply to this implicit operation.  Therefore, it is
+almost impossible to get interoperability between RT-ORBs with respect
+to this operation.  <p>
+
+Even if we make assumptions about the <CODE>_bind_priority_band</CODE>
+implicit operation and its reply, it leads to an architecture where
+there is unnecessary jitter and unpredictability because the
+connection needs to be moved from the Reactor associated with the
+Acceptor to the Reactor associated with correct priority.  This is
+either done with the <CODE>_bind_priority_band</CODE> method or with
+the first request. <p>
+
+Because of the above mentioned issues, TAO does not use
+<CODE>_bind_priority_band</CODE> operation and <CODE>
+RTCorbaPriorityRange</CODE> service context during band
+establishment. Instead, the server embeds a proprietary <CODE>
+TAO_TAG_ENDPOINTS</CODE> tagged component into an object's IOR to let
+the clients know about available priorities and corresponding
+endpoints. To establish a banded connection, the client simply uses
+the endpoint corresponding to the priority of interest. (See <a
+href="architecture.html">TAO Real-Time Architecture</a> section for
+more details.)<p>
+
+Once the semantics of the <CODE>_bind_priority_band</CODE> operation
+have been fully described by the specification or if the application
+can deal with the unpredictability of the first request, and TAO can
+be redesigned to handle the additional complexity of connection
+movement between the Reactors, we can change the behavior of Priority
+Banded Connections by:
+
+<ol>
+
+  <li>modifying client to use <CODE>bind_priority_band</CODE>
+  operation and <CODE> RTCorbaPriorityRange </CODE> service context
+  during <CODE>Object::_validate_connection()</CODE> </li>
+
+  <li>modifying server to move a connection to the appropriate reactor
+  once it receives <CODE> bind_priority_band </CODE>request and/or
+  <CODE> RTCorbaPriorityRange </CODE> service context</li>
+
+  <li>modifying client to store and look up connections based on
+  address + priority range rather than just based on address
+  alone</li> </ol>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+
+<h4><a name="2">Removing dependencies on ORB
+debug output from RTCORBA tests</a></h4>
+<p>Some of the RTCORBA tests rely on ORB debugging output for checking whether
+something works. This is <i> very</i> <i> brittle</i> since ORB developers frequently
+add/remove/modify debugging messages, causing tests to 'break', and increasing
+amount of maintenance effort required. Yet, we somehow need to verify that <i>internally</i> the ORB behaves as we expect, <i>e.g.</i>, a particular transport protocol
+is used to carry out an invocation. It may be possible to achieve this without
+depending on ORB debug messages by using Portable Interceptors or some other
+similar mechanism. For example, we could write several interceptors, which would
+obtain and print information of interest for the test. We
+should look into this.</p>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+<h4><a name="14">Adding RTCORBA examples</a></h4>
+<p>We do have tests for RTCORBA features, but what we also need are some
+examples. Use case-driven examples illustrating how certain features help
+satisfy various requirements. Examples that would help users understand
+when to use various features.</p>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+<h4><a name="5">Improving management of Private Connections</a></h4>
+<p>Currently, when the object that has private connections is destroyed, its
+connections remain in the cache. We need to implement cleanup of private
+connections on object destruction. If such cleanup is expensive, we may
+want to have it controlled by an option.</p>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+<h4><a name="6">Redesigning profile management to satisfy new requirements and
+to provide full
+support for location forwarding</a></h4>
+<p>Current client profile management code needs to change for the
+following reasons:</p>
+<ol>
+  <li>Original design assumed that all threads using the same object reference
+    would want to use the same profile for making an invocation. Hence, certain
+    state, <i>i.e.</i>, <CODE>profile_in_use, profile_sucess and forward_profiles,
+    </CODE>
+    is stored per <i>Stub</i>. This assumption no longer holds true, <i>e.g.</i>,
+    different threads may have different policies set, and would want to use
+    different profiles based on those policies. This is at least the case with
+    RTCORBA, where different threads may, for example, want to use different
+    protocols. It may also be the case in other scenarios. So, we should not keep
+    the state per <i>Stub</i>.</li>
+  <li>Current design does not properly support location forwarding more than one
+    level deep. And with certain policy configurations, location
+    forwarding is not supported at all.</li>
+  <li>Current interfaces are very polluted: many tiny functions with similar
+    names calling into each other, comments in <i> .h</i> files outdated, comments in
+    <i> .cpp</i> files mostly absent.</li>
+  <li>Lack of thorough test suite.</li>
+</ol>
+<p>Also, redesign of profile management is a good time to add support for
+<CODE>TAG_ALTERNATE_IIOP</CODE> (multiple endpoints per profile).</p>
+<p>Bala is familiar with profile management code, and has agreed to act as a
+consultant/guide when somebody tackles this item.</p>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+<h4><a name="11">Location forwarding with client-exposed policies</a></h4>
+<p>When an object is forwarded, a new set of profiles is received, and they can
+potentially include different client-exposed policies. Currently, we don't handle this case,
+<i>i.e.</i>, the set of client-exposed policies from the object's original IOR is
+used for its complete lifetime. This item is related to the <a href="#6">profile
+management</a> issue.</p>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+<h4><a name="8">Moving FT endpoint selection into the endpoint selector
+framework</a></h4>
+<p>Selection of endpoints for invocations in TAO is strategized, with strategies for
+different policy combinations located in <i>Invocation_Endpoint_Selectors.*</i>
+Bala
+may want to make FT-based endpoint selection one of the available strategies.
+(Currently it's not part of the endpoint selectors framework.)</p>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+<h4><a name="3">Introducing guidelines for debug output in TAO</a></h4>
+<p>Speaking of ORB debug output, there is not much consistency about it in TAO:
+not in the use of ORB debug levels, not in the style and detail of debug messages. It is probably a good idea to come up with a short list of
+guidelines for debugging messages - this would make the output more useful (if
+the guidelines are followed, of course ;-) )</p>
+
+<p><a href="#top">[back]</a></p>
+
+<hr>
+
+<i>
+
+<p>Last modified: $Date$ </i></p>
+<p></p>
+</body>
+</html>