Addressed Doug's comments.

1 files changed, 280 insertions, 264 deletions

diff --git a/TAO/docs/implrepo.html b/TAO/docs/implrepo.html
index 0e9b9d3befa..3a54ae7e6c2 100644
--- a/TAO/docs/implrepo.html
+++ b/TAO/docs/implrepo.html
@@ -12,20 +12,22 @@
 
 <h1>TAO Implementation Repository </h1>
 
-<p>Revision 3.02 - July 10, 1998</p>
+<p>Revision 3.03 - July 17, 1998</p>
 
 <hr>
 
 <h2>Table of Contents</h2>
 
 <ul>
+  <li><a href="#Changes">Changes</a> </li>
   <li><a href="#Overview">Overview</a> <ul>
       <li><a href="#PersistentandTransientIORs">Persistent and Transient IORs</a> </li>
       <li><a href="#TheImplementationRepository">The Implementation Repository</a> </li>
     </ul>
   </li>
   <li><a href="#TAOsImplementationRepository">TAO's Implementation Repository</a> <ul>
-      <li><a href="#VirtualServerName">Virtual Server Name</a> </li>
+      <li><a href="#VirtualServers">Virtual Servers</a> </li>
+      <li><a href="#PingObject">Ping Object</a></li>
       <li><a href="#NewIORs">New IORs</a> <ul>
           <li><a href="#WhatwaswrongwiththeoldIOR">What was wrong with the old IOR?</a> </li>
           <li><a href="#WhydoesImplRepocontainanOBJKey">Why does the Implementation Repository profile
@@ -62,108 +64,102 @@
 
 <hr>
 
+<h2><a name="Changes">Changes</a></h2>
+
+<p>Since 3.02 
+
+<ul>
+  <li>Added a section to give more detailed information on how Ping Objects work.</li>
+  <li>Rewrote the Virtual Server section</li>
+</ul>
+
+<hr>
+
 <h2><a name="Overview">Overview</a></h2>
 
-<p>This document describes the proposed design of the TAO
-Implementation Repository, which was originally known as the
-reactivator/activation service.  If you have any questions or comments
-on our design, please post them to the <A HREF="ACE-mail.html">ACE</a>
-mailing list &lt;<A
-HREF="mailto:ace-useres@cs.wustl.edu">ace-users@cs.wustl.edu</A>&gt;
-or send email to Darrell Brunsch &lt;<A
-HREF="mailto:brunsch@cs.wustl.edu">brunsch@cs.wustl.edu</a>&gt;.<P>
+<p>This document describes the proposed design of the TAO Implementation Repository, which
+was originally known as the reactivator/activation service. If you have any questions or
+comments on our design, please post them to the <a HREF="ACE-mail.html">ACE</a> mailing
+list &lt;<a HREF="mailto:ace-useres@cs.wustl.edu">ace-users@cs.wustl.edu</a>&gt; or send
+email to Darrell Brunsch &lt;<a HREF="mailto:brunsch@cs.wustl.edu">brunsch@cs.wustl.edu</a>&gt;.</p>
+<!-- DB: ACE-mail.html doesn't exist here, should it point somewhere else? -->
 
 <h3><a name="PersistentandTransientIORs">Persistent and Transient IORs</a></h3>
 
-<p>CORBA defines two types of object references: <A
-HREF="http://www.cs.wustl.edu/~schmidt/C++-report-col12.ps.gz">persistent
-and transient</A>.  The difference between the two stems from the
-lifetime of the reference in relation to the lifetime of the server
-process that created it.  The lifetime of a transient object reference
-is limited to the lifetime of its server process.  Once the server
-process exits the transient object reference no longer exists. All
-references to this object should now be invalid, even if the server is
-restarted. In contrast, persistent object references can outlive their
-originating server process.  Therefore, the server can exit and be
-restarted without invalidating its persistent object references.  This
-enables the implementation of features like automatic server
-activation and object migration.</p>
-
-<p>Note that both persistent and transient object references can refer
-to objects that reside in <EM>manually activated</EM> servers,
-<EM>i.e.</EM>, the so-called ``persistent servers.''  A persistent
-server is a server that is launched manually, <EM>i.e.</EM>, it is
-always running.  A persistent server can generate transient references
-and/or persistent references.  </P>
-
-</P>Developers should be aware that persistence of the object
-reference does not imply any persistence on the object implementation
-state.  It is certainly possible to provide persistent object
-references for objects whose state is not persistent.  Therefore,
-servant implementors are responsible for preserving the state of their
-servants, <EM>e.g.</EM>, using a database or file. </p>
+<p>CORBA defines two types of object references: <a
+HREF="http://www.cs.wustl.edu/~schmidt/C++-report-col12.ps.gz">persistent and transient</a>.
+The difference between the two stems from the lifetime of the reference in relation to the
+lifetime of the server process that created it. The lifetime of a transient object
+reference is limited to the lifetime of its server process. Once the server process exits
+the transient object reference no longer exists. All references to this object should now
+be invalid, even if the server is restarted. In contrast, persistent object references can
+outlive their originating server process. Therefore, the server can exit and be restarted
+without invalidating its persistent object references. This enables the implementation of
+features like automatic server activation and object migration.</p>
+
+<p>Note that both persistent and transient object references can refer to objects that
+reside in <em>manually activated</em> servers, <em>i.e.</em>, the so-called ``persistent
+servers.'' A persistent server is a server that is launched manually, <em>i.e.</em>, it is
+always running. A persistent server can generate transient references and/or persistent
+references. </p>
+
+<p>Developers should be aware that persistence of the object reference does not imply any
+persistence on the object implementation state. It is certainly possible to provide
+persistent object references for objects whose state is not persistent. Therefore, servant
+implementors are responsible for preserving the state of their servants, <em>e.g.</em>,
+using a database or file. </p>
 
 <h3><a name="TheImplementationRepository">The Implementation Repository</a></h3>
 
-<p>According to the CORBA specification, &quot;The Implementation
-Repository contains information that allows the ORB to locate and
-activate implementations of objects&quot; [CORBA Spec Rev. 2.2:
-2.1.14] In earlier revisions of the specification, there was a method
-<code>get_implementation</code> in the CORBA Object interface. This
-has been deprecated as of the CORBA 2.2 specification, leaving both
-the interface and implementation of the Implementation Repository to
-the ORB vendor.</p>
-
-<p>A good paper describing the functionality of the CORBA
-Implementation Repository is &quot;<a
-href="http://www.cs.wustl.edu/~schmidt/michi.pdf">Binding, Migration,
-and Scalability in CORBA</a>&quot; [Henning].  This paper describes
-the following three functions of the Implementation Repository:
+<p>According to the CORBA specification, &quot;The Implementation Repository contains
+information that allows the ORB to locate and activate implementations of objects&quot;
+[CORBA Spec Rev. 2.2: 2.1.14] In earlier revisions of the specification, there was a
+method <code>get_implementation</code> in the CORBA Object interface. This has been
+deprecated as of the CORBA 2.2 specification, leaving both the interface and
+implementation of the Implementation Repository to the ORB vendor.</p>
+
+<p>A good paper describing the functionality of the CORBA Implementation Repository is
+&quot;<a href="http://www.cs.wustl.edu/~schmidt/michi.pdf">Binding, Migration, and
+Scalability in CORBA</a>&quot; [Henning]. This paper describes the following three
+functions of the Implementation Repository: 
 
 <ol>
   <li>Maintain a registry of known servers.</li>
-  <li>Record which server is currently running, and which port and
-      host it uses.</li>
-  <li>Starts servers on demand if they are registered with the
-      Implementation Repository.</li>
+  <li>Record which server is currently running, and which port and host it uses.</li>
+  <li>Starts servers on demand if they are registered with the Implementation Repository.</li>
 </ol>
 
-<p>The TAO Implementation Repository is based on the design in this
-paper.  The next section details our goals and plans for the
-implementation.</p>
+<p>The TAO Implementation Repository is based on the design in this paper. The next
+section details our goals and plans for the implementation.</p>
 
 <hr>
 
 <h2><a name="TAOsImplementationRepository">TAO's Implementation Repository</a></h2>
 
-<p>The following is an overview of TAO'S Implementation Repository:
+<p>The following is an brief outline of TAO'S Implementation Repository. 
 
 <ul>
-  <li>Use of TAO's Implementation Repository will be optional.
-      Real-time applications can choose not to use the Implementation
-      Repository according to their
-      performance/predictability/footprint requirements.</li> 
-
-  <li>Use of TAO's Implementation Repository will be invisible to
-      clients and servers for common use-case. For more
-      complicated behavior, programs can use Implementation Repository
-      extensions of the POA.</li>
-
-  <li>TAO's Implementation Resository will work with any CORBA
-      client that supports <CODE>LOCATION_FORWARD</CODE> IIOP messages
-      and multiple profiles in IORs, even if the client is not
-      implemented using TAO.</li> 
-
-  <li>TAO's Implementation Repository will track all process that have
-      registered with it by using a &quot;ping&quot; component located in
-      the server. This ensures that multiple instances of the same
-      server are not started.
-<!-- Darrell, can you please elaborate on this a bit?  -->
-</li> 
-
-  <li>TAO will be fork-safe. Because the Implementation Repository will need to use fork/exec
-    (or CreateProcess on NT) to launch servers, the open connection to
-    the client will need to be preserved over the server creation.</li>
+  <li>Use of TAO's Implementation Repository will be optional. Real-time applications can
+    choose not to use the Implementation Repository according to their
+    performance/predictability/footprint requirements.</li>
+  <li>Use of TAO's Implementation Repository will be invisible to clients and servers for
+    common use-case. For more complicated behavior, programs can use Implementation Repository
+    extensions of the POA.</li>
+  <li>TAO's Implementation Repository will work with any CORBA client that supports <code>LOCATION_FORWARD</code>
+    IIOP messages and multiple profiles in IORs, even if the client is not implemented using
+    TAO.</li>
+  <li>TAO's Implementation Repository will know if one of the servers registered with it is
+    running by the use of a &quot;ping&quot; like mechanism in the server. This allows the
+    Implementation Repository to know when it should restart the server.</li>
+<!-- DCS: Darrell, can you please elaborate on this a bit?  -->
+<!-- DB: Rephrased this bullet and also added a section about the -->
+<!-- DB: ping object and the results of a quick discussion with -->
+<!-- DB: Carlos about this stuff. -->
+<!-- DB: BTW, you don't have to say "Darrell," every time since I'm -->
+<!-- DB: pretty much the default editor of the paper.  ;-)  -->
+  <li>TAO will be fork-safe. Since there will be an open connection to the client while the
+    server is restarted (via fork or CreateProcess) then care will be needed to make sure that
+    the open sockets will be closed in the client process. This will remove a resource leak. </li>
 <!-- COR: Maybe I didn't explain myself properly when we discussed -->
 <!-- COR: this, I would expect that after fork all connections are -->
 <!-- COR: closed on the server, otherwise we will end up leaking -->
@@ -171,53 +167,75 @@ implementation.</p>
 <!-- DB: Then I'm not sure how are we supposed to return a LOCATION -->
 <!-- DB: FORWARD if we have to close the connection? -->
 <!-- DCS: Darrell, I think it's ok to close the connection, as long as -->
-<!-- we set up the right port number for the child process to listen -->
-<!-- at, right?  Can you please clarify this a bit more in the text, BTW? -->
-
+<!-- DCS: we set up the right port number for the child process to listen -->
+<!-- DCS: at, right?  Can you please clarify this a bit more in the text, BTW? -->
+<!-- DB: Okay, I figured out what was going on and rewrote the bullet -->
   <li>TAO will exploit features of IIOP 1.1 to safely and efficiently verify if an IOR was
     generated by TAO itself on the client side. The server will still determine this through
     the object key, since that is all that is passed in a request.</li>
-
-  <li>TAO will support multiple profiles. 
-<!-- Darrell, can you please clarify this just a bit, i.e., explain -->
-<!-- what it means to support multiple profiles? -->
-     Our goal is to have the clients contact the object first, and if
-      that fails, then contact the Implementation Repository. 
-<!-- Darrell, can you please clarify what the motivation is for the -->
-<!-- Implementation Repository? -->
-</li>
+  <li>TAO will support multiple profiles in IORSs. A profile contains the host/port and object
+    key of a CORBA Object. An optimization that will be possible is to have a last known
+    profile of the object as the first profile and an Implementation Repository as the seconf
+    profile in an IOR. The client will first try the object to see if it still active at the
+    host/port before it contacts the Implementation Repository. </li>
+<!-- DCS: Darrell, can you please clarify this just a bit, i.e., explain -->
+<!-- DCS: what it means to support multiple profiles? -->
+<!-- DB: Rephrased the above bullet. -->
 </ul>
+<!-- DCS: Darrell, can you please clarify what the motivation is for the -->
+<!-- DCS: Implementation Repository? -->
+<!-- DB: How should this motivation different than the motivation in the -->
+<!-- DB: Overview sections? Or is it just a summary of it?  -->
+
+<h3><a name="VirtualServers">Virtual Servers</a></h3>
+
+<p>TAO's Implementation Repository must keep track of whether an object's implementation
+is currently running or is stopped. To have a record for every object would require too
+much overhead, but having a record for every executable server would be inflexible and
+prevent the migration of objects. In the <a
+href="http://www.cs.wustl.edu/~schmidt/michi.pdf">Henning</a> paper, he mentions the use
+of a <em>server name</em> as the index for the table maintained by the Implementation
+Repository. </p>
 
-<h3><a name="VirtualServerName">Virtual Server Name</a></h3>
-
-<p>TAO's Implementation Repository must track which servers are
-started and stopped.  The question is at what resolution?  For
-instance, it cannot contain an entry for every object, since that
-isn't time and space efficient.  It could contain an entry for every
-server, and then group objects there. But that approach is inflexible
-for object migration since objects are tied to their
-executable. Instead, we want TAO's Implementation Repository to store
-something in between an object and an executable. In the <a
-href="http://www.cs.wustl.edu/~schmidt/michi.pdf">Henning</a> paper,
-he mentions the use of a <EM>server name</EM> as the index for the
-table maintained by the Implementation Repository. </p>
-<!-- Darrell, can you please briefly explain what a server name is and -->
-<!-- how it will be defined, i.e., by the application? -->
-
-<p>We will use a virtual server name for a group of objects. 
-<!-- Darrell, can you please define what a "virtual server name" is briefly?
-The virtual server isn't restricted to being tied to an executable
-or to an object. Since it isn't tied to an executable, the virtual
-servers can be migrated to other servers.</p>
-<!-- Darrell, can you please elaborate on this a bit?  It's not clear -->
-<!-- why a virtual server enables migration! -->
+<p>The virtual server does not refer to the executable but instead to a group of objects.
+An executable may have one or more virtual servers on it. This allows one virtual server
+to be moved off the executable to another executable (for instance, onto another machine)
+without affecting the objects in other virtual servers on the original executable. </p>
+
+<p>Each virtual server will be indexed in the Implementation Repository by a name that is
+given to it by the user. It is also the users responsibility to make sure that each
+virtual server name is unique. By default this name is the name of the executable (since
+by default there is only one virtual server per executable) but this behavior can be
+overridden. </p>
+<!-- DCS: Darrell, can you please define what a "virtual server name" is briefly? -->
+<!-- DCS: Darrell, can you please elaborate on this a bit?  It's not clear -->
+<!-- DCS: why a virtual server enables migration! -->
+<!-- DB: Rewrote the above. -->
+
+<h3><a name="PingObject">Ping Object</a></h3>
+
+<p>Ping objects are simple objects that reside in the server, one for every virtual
+server. It is contacted by the Implementation Repository to determine if the virtual
+server is still running and responding. At certain intervals the Implementation Repository
+will invoke a one-way method on the ping object, and then will expect a &quot;pong&quot;
+message to be sent back. Different strategies for pinging will be used by the
+implementation repository. If a server is expected to be responsive, the Implementation
+Repository will not wait long for a response before considering the server to be gone.
+Other servers may be computationally-intensive and need to be held under less stringent
+expectations.</p>
+
+<p>We chose the ping method to be a one-way (instead of two-way) because if the server
+became unresponsive, it would not return from the method invocation. The Implementation
+Repository needs some form of a timeout with the ping to be able to determine if the
+server is unresponsive or not.</p>
 
 <h3><a name="NewIORs">New IORs</a></h3>
 
 <p>Standard CORBA IORs contain the following two sections:</p>
+<!-- DCS: Darrell, can you please briefly explain what a "Type ID" and a -->
+<!-- DCS: "Sequence of Tagged Profiles" are? -->
+<!-- DB: Done below -->
 
-<!-- Darrell, can you please briefly explain what a "Type ID" and a -->
-<!-- "Sequence of Tagged Profiles" are? -->
 <table border="1">
   <tr>
     <td>Type ID</td>
@@ -225,8 +243,13 @@ servers can be migrated to other servers.</p>
   </tr>
 </table>
 
-<p>Currently, TAO uses only one IIOP 1.0 Tagged Profile, which is
-defined as follows:</p>
+<p>The Type ID is an indicator for the most derived type known at the time of the
+reference creation. It is used as a hint for the client in determining what interfaces the
+object can support. The Sequence of Tagged Profiles consist of one or more profiles that
+encapsulate information used by the associated protocol in order to communicate with the
+object (host, port, object id, etc.).</p>
+
+<p>Currently, TAO uses only one IIOP 1.0 Tagged Profile, which is defined as follows:</p>
 
 <table border="1">
   <tr>
@@ -252,8 +275,8 @@ defined as follows:</p>
   </tr>
 </table>
 
-<p>To accomodate the Implementation Repository and IIOP 1.1, the
-Profile was changed in the CORBA specification as follows:</p>
+<p>To accomodate the Implementation Repository and IIOP 1.1, the Profile was changed in
+the CORBA specification as follows:</p>
 
 <table border="1">
   <tr>
@@ -281,12 +304,12 @@ Profile was changed in the CORBA specification as follows:</p>
   </tr>
 </table>
 
-<p>In TAO, Transient objects will have a TimeStamp to ensure
-uniqueness.  Likewise, persistent object will have a server name to
-identify them in the Implementation Repository.</p>
+<p>In TAO, Transient objects will have a TimeStamp to ensure uniqueness. Likewise,
+persistent object will have a server name to identify them in the Implementation
+Repository.</p>
 
-<p>For Persistent IORs, a second tagged profile will be added in TAO
-to point to the Implementation Repository, as follows:</p>
+<p>For Persistent IORs, a second tagged profile will be added in TAO to point to the
+Implementation Repository, as follows:</p>
 
 <table border="1">
   <tr>
@@ -314,48 +337,44 @@ to point to the Implementation Repository, as follows:</p>
   </tr>
 </table>
 
-<p>If the profile was meant for just calls to the Implementation
-Repository, then the OBJ ID would be that of the Implementation
-Repository Object.</p>
+<p>If the profile was meant for just calls to the Implementation Repository, then the OBJ
+ID would be that of the Implementation Repository Object.</p>
 
 <h4><a name="WhatwaswrongwiththeoldIOR">What was wrong with the old IOR?</a></h4>
 
-<p>We need a place to put a TAO marker in the IOR it so TAO servers
-can differentiate TAO IORs from IORs of other vendors. In the original
-scheme used in TAO, Persistent IORs had a null timestamp. To support
-virtual servers, we will use that slot to store the server name so the
-Implementation Repository knows which server to launch.</p>
+<p>We need a place to put a TAO marker in the IOR it so TAO servers can differentiate TAO
+IORs from IORs of other vendors. In the original scheme used in TAO, Persistent IORs had a
+null timestamp. To support virtual servers, we will use that slot to store the server name
+so the Implementation Repository knows which server to launch.</p>
 
 <h4><a name="WhydoesImplRepocontainanOBJKey">Why does the Implementation Repository
 profile contain an Object Key?</a></h4>
 
-<p>It needs to know what the object key of the object when forwarding
-is used. A server may contain more than one.
-<!-- Darrell, "more than one" what?! -->
- </p>
+<p>It needs to know what the object key of the object when forwarding is used. A server
+may contain more than one object, so the object key is needed to forward to the correct
+object on the server. </p>
+<!-- DCS: Darrell, "more than one" what?! -->
+<!-- DB: Added.-->
 
 <h3><a name="POAExtensions">POA Extensions</a></h3>
 
-<p>TAO's POA will contain an new TAO-specific method called
-<code>create_reference_with_virtual_server[_and_id] (...)</code>.
-This method takes additional arguments for a virtual server name and a
-sequence of Implementation Repository IORs. This method will
-communicate with each Implementation Repository 
-<!-- Darrell, I'm not sure what you mean by "each Implementation -->
-<!-- Repository?"  Are there more than one?  Can you please clarify this?
-and get its generated profile back. Then all the profiles will be
-combined to produce an Persistent IOR.</p>
+<p>TAO's POA will contain a new TAO-specific method called <code>create_reference_with_virtual_server[_and_id]
+(...)</code>. This method takes additional arguments for a virtual server name and a
+sequence of Implementation Repository IORs. The POA will register the virtual server name
+with each of the Implementation Repositories in the sequence passed in. Several
+Implementation Repositories may be specified for redundancy. </p>
+<!-- DCS: Darrell, I'm not sure what you mean by "each Implementation -->
+<!-- DCS: Repository?"  Are there more than one?  Can you please clarify this?-->
+<!-- DB: Added more info on multiple IRs -->
 
 <h3><a name="PossibleFutureGoals">Possible Future Goals</a></h3>
 
-<p>The following are features that may be added to support TAO's
-Implementation Repository:
+<p>The following are features that may be added to support TAO's Implementation
+Repository: 
 
 <ul>
-  <li>Optimization on TAO clients to recognize when a server is
-    restarted, and change all other IORs that contain the server
-    instead of going through the Implementation Repository</li>
-
+  <li>Optimization on TAO clients to recognize when a server is restarted, and change all
+    other IORs that contain the server instead of going through the Implementation Repository</li>
   <li>Some sort of server security that checks the executable to make sure it is the correct
     executable (checksum, signatures, etc).</li>
   <li>Add the ability to put servers into DLLs or Shared Object files so the Implementation
@@ -367,21 +386,23 @@ Implementation Repository:
 
 <h3><a name="ServerRestrictions">Server Restrictions</a></h3>
 
-<p>Servers that are restarted by the Implementation Repository must be
-able to recreate enough state to deal with requests from a
-client. Unless dynamic servant and POA activation is used, the
-restarted server must also recreate the POA in which the object
-associated with the persistent object reference was registered and
-register this object with that POA. </p>
+<p>Most often servers that have Persistent IORs will save their state to secondary
+storage. Databases are a good example of this, where the server can be stopped and
+restarted with all the information remaining on disk. </p>
 
-<!-- Darrell, can you please elaborate briefly on how these -->
-<!-- restrictions actually affect the way that a TAO server is -->
-<!-- written? -->
+<p>The server must also make sure it creates the POA and Object in a way that does not
+change the POA ID and Object ID. The Implementation Repository forwards requests based on
+the information in the IOR; if the POA ID or Object ID changes, then the Implementation
+Repository will be unable to sucessfully forward requests. If the server implements
+dynamic servants with POA activation, then this is not an issue.</p>
+<!-- DCS: Darrell, can you please elaborate briefly on how these -->
+<!-- DCS: restrictions actually affect the way that a TAO server is -->
+<!-- DCS: written? -->
+<!-- DB: I rewrote this in a way that seems a bit clearer to me. -->
 
 <h3><a name="PreliminaryInterface">Preliminary Interface</a></h3>
 
-<p>The following is a proposed IDL interface for the TAO Implementation
-Repository: </p>
+<p>The following is a proposed IDL interface for the TAO Implementation Repository: </p>
 
 <pre>module TAO
 {
@@ -438,10 +459,14 @@ Repository: </p>
 
   interface Ping_Object
   {
-    void ping ();
-    // Used for checking for liveness of a server.
-<!-- Darrell, can you please explain how this ping() will work, i.e., -->
-<!-- will it throw an exception if the server isn't live? -->
+    oneway void ping ();
+    // Used for checking for liveness of a server.  When the server receives
+    // this, it should send back a response indicating it is sill alive.  
+    // Depending on the policy specified, a timeout can be reached where the
+    // Implementation Repository will restart the server.
+<!-- DCS: Darrell, can you please explain how this ping() will work, i.e., -->
+<!-- DCS: will it throw an exception if the server isn't live? -->
+<!-- DB: Ok.  But do oneways also return exceptions? -->
   };
 
   interface Implementation_Repository
@@ -513,109 +538,104 @@ Repository: </p>
 
 <h2><a name="AlternateImplementations">Alternate Implementations</a></h2>
 
-<p>Other ORB vendors use alternative techniques for their
-Implementation Repositories.  These techniques usually require new
-naming techniques to access persistent object references and new
-client-side APIs to bind to persistent object references. TAO's
+<p>Other ORB vendors use alternative techniques for their Implementation Repositories.
+These techniques usually require new naming techniques to access persistent object
+references and new client-side APIs to bind to persistent object references. TAO's
 Implementation Repository will not require such extensions. </p>
 
-<p>Another design of an Implementation Repository uses an Object
-Reference that points to the Implementation Repository instead of
-pointing directly to the persistent object. This extra level of
-indirection is used by the Implementation Repository to start the
-server (if needed), and then use the Location Forwarding mechanism to
-forward the client request to the server. This technique forces
-clients to use the Implementation Repository (at least once) even when
-the server is already running. </p>
-
-<!-- Darrell, I don't see how we can get away from doing this as a -->
-<!-- bootstrapping technique.  Can you please explain where in the -->
-<!-- document we discuss how to avoid this initial indirection? -->
+<p>Another design of an Implementation Repository uses an Object Reference that points to
+the Implementation Repository instead of pointing directly to the persistent object. This
+extra level of indirection is used by the Implementation Repository to start the server
+(if needed), and then uses the Location Forwarding mechanism to forward the client request
+to the server. The difference between this design and TAO's design is that the persistent
+IOR in TAO will contain a profile pointing to a location of the server (where it still
+might be running) to try first, and then only if that fails does the client contact the
+Implementation Repository. This is an optimization for case where the server does not shut
+down often, and most requests do not need to be forwarded to a new address.</p>
+
+<p>In cases where most requests will require a forward, TAO can support a policy that is
+just like this alternative, where the Implmentation Repository will be contacted first.</p>
+<!-- DCS: Darrell, I don't see how we can get away from doing this as a -->
+<!-- DCS: bootstrapping technique.  Can you please explain where in the -->
+<!-- DCS: document we discuss how to avoid this initial indirection? -->
+<!-- DB: Does the above clear this up, or are you asking for something more -->
+<!-- DB: about how the helper application registers the virtual server name -->
+<!-- DB: or how the server finds out about the IR when it starts up (or is -->
+<!-- DB: restarted). -->
 
 <hr>
 
 <h2><a name="AccessingtheImplementationRepository">Accessing the Implementation Repository</a>
 </h2>
 
-<p>The Implementation Repository will be transparent to the clients
-and the servers. </p>
-<!-- Darrell, that's not entirely correct since the server program -->
-<!-- must register its virtual server name, right? -->
+<p>The Implementation Repository will be transparent to the clients and the servers.
+Clients will only deal with IIOP 1.1 IORs, and in the default case all the Implementation
+Repository logic on the server side will be handled internally by the ORB and the POA. </p>
+<!-- DCS: Darrell, that's not entirely correct since the server program -->
+<!-- DCS: must register its virtual server name, right? -->
+<!-- DB: Addressed above (default case it is transparent for servers) -->
 
 <h3><a name="HelperApplication">Helper Application</a></h3>
 
-<p>A helper application will be included with the Implementation
-Repository. It will be a command-line utility that will assist users
-with adding and removing server records (containing virtual server
-names and executable name/options) from the Implementation
+<p>A helper application will be included with the Implementation Repository. It will be a
+command-line utility that will assist users with adding and removing server records
+(containing virtual server names and executable name/options) from the Implementation
 Repository. </p>
+<!-- DCS: Darrell, I recommend that you take a look at how VisiBroker and -->
+<!-- DCS: Orbix do this and write a short explanation of the command-line -->
+<!-- DCS: utilities you propose to use! -->
+<!-- DB: @@ Looking at them right now. -->
 
-<!-- Darrell, I recommend that you take a look at how VisiBroker and -->
-<!-- Orbix do this and write a short explanation of the command-line -->
-<!-- utilities you propose to use! -->
-
-<h3><a name="LocatinganinstanceofImplRepo">Locating an Instance of the
-Implementation Repository </a></h3>
+<h3><a name="LocatinganinstanceofImplRepo">Locating an Instance of the Implementation
+Repository </a></h3>
 
 <h4><a name="Serverside">Server-side</a></h4>
 
-<p>In the default case, the Implementation Repository will be found
-via the command-line, environment variables, and multicast (in that
-order).  This location strategy is consistent with that used by TAO to
-local its default Naming Service instance. Using the POA extensions,
-other Implementation Repositories can be specified in the call to
-<code>POA::create_reference_with_virtual_server</code>.  The default
-port of the Implementation Repository can be overridden through
-command-line options or environment variables. </p>
+<p>In the default case, the Implementation Repository will be found via the command-line,
+environment variables, and multicast (in that order). This location strategy is consistent
+with that used by TAO to local its default Naming Service instance. Using the POA
+extensions, other Implementation Repositories can be specified in the call to <code>POA::create_reference_with_virtual_server</code>.
+The default port of the Implementation Repository can be overridden through command-line
+options or environment variables. </p>
 
 <h4><a name="Clientside">Client-side</a></h4>
 
-<p>One or more Implementation Repositories will be stored in
-additional profiles in the IOR.
-<!-- Darrell, please make sure you explain why a client might need -->
-<!-- multiple Implementation Repositories. -->
-Other Implementation Repositories can also be located by multicasting
-(on a default multicast group) the server name of the Persistent
-Object the client is interested in. The default multicast group and
-default port of the Implementation Repository can be overridden
-through command line options or environment variables. </p>
+<p>One or more Implementation Repositories will be stored in additional profiles in the
+IOR. Other Implementation Repositories can also be located by multicasting (on a default
+multicast group) the server name of the Persistent Object the client is interested in. The
+default multicast group and default port of the Implementation Repository can be
+overridden through command line options or environment variables. </p>
+
+<p>In most cases, one Implementation Repository will be enough. For redundancy several
+Implementation Repositories can be specified.</p>
+<!-- DCS: Darrell, please make sure you explain why a client might need -->
+<!-- DCS: multiple Implementation Repositories. -->
+<!-- DB: Added it above. -->
 
 <hr>
 
 <h2><a name="Howitworks">How It Works</a></h2>
 
-<h3><a name="HowServerProducesPersistentIORdefault">How a server
-produces a Persistent IOR (in the default case)</a></h3>
-
-<p>Before a server starts, it must be registered (via a command-line
-utility) with an implementation repository that supports
-multicast. </p>
-<!-- COR: is multicast support mandatory? OTOH it will be there -->
-<!-- COR: always, right? -->
-<!-- DB: I'm taking the default case to be that you wrote your -->
-<!-- DB: before all this Impl Repo stuff came about.  So you -->
-<!-- DB: won't have any environment variables or command line -->
-<!-- DB: options that deal with the Impl Repo, so multicast is -->
-<!-- DB: the only way we can do it without any work from the -->
-<!-- DB: the user. -->
+<h3><a name="HowServerProducesPersistentIORdefault">How a server produces a Persistent IOR
+(in the default case)</a></h3>
 
-<ol>
+<p>Before a server starts, it must be registered (via a command-line utility) with an
+implementation repository. On platforms that don't support multicast, the Implementation
+Repository must be specified on the command line or in an environment variable. 
 
-  <li>Now the server will start up and call
-  <code>ORB_init</code>. <code>ORB_init</code>, if
+<ol>
+  <li>Now the server will start up and call <code>ORB_init</code>. <code>ORB_init</code>, if
     not passed a server name, will take argv[0] and use that as a default server name (TAO
     expects this to be the executable name). </li>
-
   <li><code>ORB_init</code> will create a ping object.</li>
-
-  <li><code>ORB_init</code> will look for Implementation Repositories
-    on the command-line, environmental variables, and then through
-    multicast (in that order). Once it finds one it registers itself
-    and passes the ping object to the implementation repository with
-    <CODE>server_is_running</CODE> operation.
-<!-- Darrell, can you clarify if this a standard OMG CORBA operation -->
-<!-- or a TAO extension? -->
-</li>
+  <li><code>ORB_init</code> will look for Implementation Repositories on the command-line,
+    environmental variables, and then through multicast (in that order). Once it finds one it
+    registers itself and passes the ping object to the implementation repository with <code>server_is_running</code>
+    operation. </li>
+<!-- DCS: Darrell, can you clarify if this a standard OMG CORBA operation -->
+<!-- DCS: or a TAO extension? -->
+<!-- DB: I'm guessing you are referring to the communication between the -->
+<!-- DB: server and IR.  If so, done above.-->
   <li>The profile returned by registration will be stored for later use.</li>
   <li>Client later can call the <code>POA::create_reference</code> operation.</li>
   <li>The <code>create_reference</code> operation will create the local profile.</li>
@@ -627,21 +647,19 @@ multicast. </p>
 <h3><a name="HowServerProducesPersistentIORcomplex">How a server produces a Persistent IOR
 (in complex cases)</a></h3>
 
-<p>As with the default case, the server must be registered with an
-Implementation Repository, although it does not need to be multicast
-aware.
-<!-- Darrell, can you please clarify why it need not be multicast -->
-<!-- aware? -->
+<p>As with the default case, the server must be registered with an Implementation
+Repository, although it does not need to be multicast aware since the IORs will be passed
+to the POA by the program. </p>
+<!-- DCS: Darrell, can you please clarify why it need not be multicast -->
+<!-- DCS: aware? -->
+<!-- DB: done. -->
 
 <ol>
   <li><code>ORB_init</code> is called and does the default work (if it has Implementation
     Repositories to contact).</li>
-
   <li><code>POA::create_reference_with_virtual_server[_and_id]</code> will be called with a
     server name and list of Implementation Repositories. </li>
-
   <li>The profile for the object is created.</li>
-
   <li>The ping object created in <code>ORB_init</code> and the object key is passed to the
     Implementation Repositories, and their profiles are returned.</li>
   <li>The full IOR is built and returned.</li>
@@ -661,17 +679,16 @@ aware.
     either return NOT_FOUND or will start up the server and return a Location Forward message.</li>
 </ul>
 
-<p>If everything fails, then most clients will return failure for the
-request. TAO clients will also have added functionality where other
-Implementation Repositories can be specified on the command-line, in
-environment variables, or found through multicast will also be
-contacted.
+<p>If everything fails, then most clients will return failure for the request. TAO clients
+will also have added functionality where other Implementation Repositories can be
+specified on the command-line, in environment variables, or found through multicast will
+also be contacted. 
 
 <ul>
   <li>If all of the profiles fail, then contact the other Implementation Repositories. First
     get those specified on the command line or in environment variables.</li>
   <li>Then, if multicast is available: <ul>
-      <li>Multicast the Object Reference to a group of Implementation Repositories&nbsp; </li>
+      <li>Multicast the Object Reference to a group of Implementation Repositories </li>
       <li>Wait until response or a timeout. The response will contain the Object Reference of a
         Implementation Repository that knows about the Object Reference </li>
     </ul>
@@ -683,10 +700,9 @@ contacted.
   <li>If a null reference was sent back, then fail.</li>
 </ul>
 
-<p>TAO clients will have an optimization where if there are several
-IORs that have the same server name, and one of them gets forwarded,
-then the client will be able to change its other IORs without going
-through the overhead of contacting Implementation Repository.</p>
+<p>TAO clients will have an optimization where if there are several IORs that have the
+same server name, and one of them gets forwarded, then the client will be able to change
+its other IORs without going through the overhead of contacting Implementation Repository.</p>
 
 <hr>