ChangeLogTag:Wed Jan 06 09:04:46 1999 Carlos O'Ryan <coryan@JIG>

4 files changed, 142 insertions, 93 deletions

diff --git a/TAO/ChangeLog-98c b/TAO/ChangeLog-98c
index 598050a28cf..41a54eecae7 100644
--- a/TAO/ChangeLog-98c
+++ b/TAO/ChangeLog-98c
@@ -1,3 +1,15 @@
+Wed Jan 06 09:04:46 1999  Carlos O'Ryan  <coryan@JIG>
+
+	* docs/releasenotes/TODO.html: 
+	  Updated the information about EC related tasks.
+
+	* docs/releasenotes/ec.html: 
+	  Added the new features in the EC; removed the entries about a
+	  missing CosEventChannel, because we have one now!
+
+	* docs/releasenotes/index.html: 
+	  Added some comments for Pradeep.
+
 Wed Jan  6 07:44:24 1999  Carlos O'Ryan  <coryan@cs.wustl.edu>
 
 	* tao/DynStruct_i.cpp: 
diff --git a/TAO/docs/releasenotes/TODO.html b/TAO/docs/releasenotes/TODO.html
index d55076e5fa8..7a542f05927 100644
--- a/TAO/docs/releasenotes/TODO.html
+++ b/TAO/docs/releasenotes/TODO.html
@@ -44,9 +44,60 @@
         </P>
       </LI>
 
-      <LI><P><B>EC:</B> Build a COS Event Channel on top of the RTEC
-	Event Service.
-        <BR>[ASSIGNED TO:] Pradeep
+      <LI><P>Implement a nice example of the COS Event Channel,
+          showing how it can provide filtering when combined with the
+          real-time Event Channel.
+          <BR>[ASSIGNED TO:] Pradeep
+        </P>
+      </LI>
+
+      <LI><P><B>EC:</B> The current architecture of the real-time
+          Event Channel does not support some features, such as:
+	  <UL>
+	    <LI><P><B>EC:</B> Some applications are both suppliers and
+                consumers of events,
+                they may be interested in all the
+                events of type <B>T</B> unless the event is generated
+		by them.
+            </LI>
+            <LI><P><B>EC:</B> Can we factor out the scheduling service from
+                the EC?
+              </P>
+            </LI>
+
+            <LI><P><B>EC:</B> The reactive event channel can eliminate
+                data copies because the data does not need to survive
+		after the <CODE>push()</CODE> call.
+              </P>
+            </LI>
+
+	    <LI><P><B>EC:</B> Many applications require to intercept
+	        the EC event processing, for example to keep track of
+		the number of events received and sent. 
+                This requires strategized factories for many (if not
+		all) of the Event Channel internal servants.
+               </P>
+             </LI>
+
+	    <LI><P><B>EC:</B> Some applications require ad-hoc
+                filters, such as "this events must arrive in
+                sequence", or "wait for all this events and then send
+                this other event".
+               </P>
+             </LI>
+
+            <!-- This is Boeing specific -->
+            <LI><P><B>EC:</B> For some applications it is insteresting
+                to activate the EC servants (such as the
+                ConsumerProxys) in different POAs
+              </P>
+            </LI>
+      
+          </UL>
+	  We have completed a new design for the real-time event
+          channel that will let us implement all this features (and
+          others).
+          <BR>[ASSIGNED TO:] Carlos
         </P>
       </LI>
 
@@ -211,28 +262,6 @@
 
     <H4>New features and Bug fixes</H4>
     <OL>
-      <LI><P><B>EC:</B> Some applications are both suppliers and
-          consumers of events,
-          they may be interested in all the
-          events of type <B>T</B> unless the event is generated by
-          them.
-          Investigate if the current architecture can support that,
-          it may be necessary to augment the filtering module to
-          insert a <B>not this source</B> primitive.
-        </P>
-      </LI>
-
-      <LI><P><B>EC:</B> Can we factor out the scheduling service from
-          the EC?
-        </P>
-      </LI>
-
-      <LI><P><B>EC:</B> The reactive event channel can eliminate data
-          copies because the data does not need to survive after the
-          <CODE>push()</CODE> call.
-        </P>
-      </LI>
-
       <LI><P><B>EC:</B>Sometimes the Event Channel dead-locks during
           shutdown. According to Ulf Jährig &lt;jaehrig@desys.com&gt>;, an
           easy way to reproduce the problem is to run the
@@ -703,13 +732,6 @@ class POA_Foo {
         </P>
       </LI>
 
-      <!-- This is Boeing specific -->
-      <LI><P><B>EC:</B> For some applications it is insteresting to
-          activate the EC servants (such as the ConsumerProxys) in
-          different POAs
-        </P>
-      </LI>
-      
       <LI><P><B>IDL Compiler:</B> The CORBA 2.3 spec clarifies the scope of a
           <CODE>#pragma prefix</CODE>:
           the prefix is supposed to get cleared after each
@@ -976,6 +998,12 @@ encapsulation format.
       <H3>Completed Tasks</H3>
 
     <OL>
+      <LI><P><B>EC:</B> Build a COS Event Channel on top of the RTEC
+	Event Service.
+        <BR>[ASSIGNED TO:] Pradeep
+        </P>
+      </LI>
+
       <LI><P><B>EC:</B>Implement fragmentation and reassembly of UDP
           messages. This is important for an effective implementation
           of the multicast version of the EC. The classes affected
diff --git a/TAO/docs/releasenotes/ec.html b/TAO/docs/releasenotes/ec.html
index 16b977f90ba..89c4fb506e8 100644
--- a/TAO/docs/releasenotes/ec.html
+++ b/TAO/docs/releasenotes/ec.html
@@ -16,25 +16,11 @@ Last Updated: $Date$</H4>
 <H3>
 New on this release</H3>
 
-<UL>Continued work on the multicast support for the EC, we added a new
-server that maps the event types (and supplier ids) into the right mcast
-group. Usually this server is collocated with the helper classes that send
-the events through multicast, so using a CORBA interface for this mapping
-is not expensive, further it adds the flexibility of using a global service
-with complete knowledge of the traffic in the system, that could try to
-optimize multicast group usage.
-<P>The subscriptions and publications on a particular EC can be remotely
-observed by instances of the <TT>RtecChannelAdmin::Observer</TT> class.
-Once more using CORBA for this interface cost us little or nothing because
-it is usually used by objects collocated with the EC.
-<P><TT>TAO_EC_UDP_Receiver</TT> is a helper class that receives events
-from multicast groups and dispatches them as a supplier to some event channel.
-This class has to <B>join</B> the right multicast groups, using the <TT>Observer</TT>
-described above and the <TT>RtecUDPAdmin</TT> to map the subscriptions
-into multicast groups it can do this dynamically, as consumers join or
-leave its Event Channel.
-<P>When sending Events through multicast all the <TT>TAO_EC_UDP_Sender</TT>
-objects can shared the same socket.</UL>
+<UL>
+  <LI><P>Added fragmentation and reassembly support for the multicast
+    gateways</P>
+  </LI>
+</UL>
 
 <H3>
 Known issues:</H3>
@@ -85,40 +71,18 @@ ACE Service Configurator; currently the services must be explicitly instantiated
 by the user.
 <DT>
 
-<P><I>The <TT>TAO_EC_Gateway_IIOP</TT> objects publish events coming from
-multiple suppliers</I></DT>
-
-<P>This objects receive the events from a "remote" EC and pushes them into
-a "local" EC, it subscribes to the disjunction of the events in the local
-consumers and it uses the same event types/<TT>supplier_ids</TT> to connect
-as a local supplier. This list may potentially include several different
-subscriptions based on different supplier ids, so the <TT>Gateway</TT>
-may end up with an invalid publication. We need to have different local
-suppliers for each remote <TT>supplier_id</TT> potentially shared between
-all the local <TT>Gateways</TT>.
-<DT>
-
-<P><I>There is no <TT>CosEventChannel</TT> interface</I></DT>
-
-<P>This is more of a warning than an issue. TAO's Real-time Event Channel
-is <B>not</B> an implementation of the CORBAservices Event Channel; it
-provides a similar set of features, and the interfaces are also similar,
-but real-time applications require more control over their middleware than
-what the CORBA Event Channel provides.
-<P>It should also be noted that the Event Channel only provides the <B>Push</B>
-model, since it is more predictable and it can be reuse the scheduling
-algorithms uses for normal function calls.
-<P>It would be fairly simple to implement a standard CORBA Event Service
-on top of TAO's Real-time Event Channel, but this is a low priority task,
-since our sponsors have no need for such a beast.
 <DT>
 <P><I>Further details:</I></DT>
 
 <P>Many lower level issues and tasks can be found in the <A HREF="TODO.html">TODO
-list</A>.</DL>
+list</A>.
+
+</DL>
 
 <H3>
 Examples</H3>
+
+
 For general documentation on the Event Service please read <A HREF="http://www.cs.wustl.edu/~schmidt/oopsla.ps.gz">The
 Design and Performance of a Real-time CORBA Event Service</A>.
 <P>The simplest test for the Event Channel is <TT>Event_Latency</TT>, below
@@ -149,10 +113,35 @@ inversion, since only one thread runs at a time.</LI>
 </OL>
 Another example is <TT>EC_Multiple</TT>, numerous examples on how to run
 this test can be found in the scripts located in <TT>$TAO_ROOT/orbsvcs/tests/EC_Multiple</TT>.
+
 <H3>
 Features in previous releases</H3>
 
-<UL>Added a prototype Consumer and Supplier that can send events though
+<UL>
+
+<LI><P>Continued work on the multicast support for the EC, we added a new
+server that maps the event types (and supplier ids) into the right mcast
+group. Usually this server is collocated with the helper classes that send
+the events through multicast, so using a CORBA interface for this mapping
+is not expensive, further it adds the flexibility of using a global service
+with complete knowledge of the traffic in the system, that could try to
+optimize multicast group usage.
+<P>The subscriptions and publications on a particular EC can be remotely
+observed by instances of the <TT>RtecChannelAdmin::Observer</TT> class.
+Once more using CORBA for this interface cost us little or nothing because
+it is usually used by objects collocated with the EC.
+<P><TT>TAO_EC_UDP_Receiver</TT> is a helper class that receives events
+from multicast groups and dispatches them as a supplier to some event channel.
+This class has to <B>join</B> the right multicast groups, using the <TT>Observer</TT>
+described above and the <TT>RtecUDPAdmin</TT> to map the subscriptions
+into multicast groups it can do this dynamically, as consumers join or
+leave its Event Channel.
+<P>When sending Events through multicast all the <TT>TAO_EC_UDP_Sender</TT>
+objects can shared the same socket.
+</P>
+</LI>
+
+<LI><P>Added a prototype Consumer and Supplier that can send events though
 multicast groups (or regular UDP sockets).
 <P>The Event Channel can be configured using a Factory that constructs
 the right modules (like changing the dispatching module), in the current
@@ -174,34 +163,51 @@ basically hardcodes all the subscriptions and publications, we are researching
 on how to automatically build the publication list.
 <P>We use the COS Time Service types (not the services) to specify time
 for the Event Service and Scheduling Service.
+</P>
+</LI>
+
 <LI>
-The <TT>Gateway</TT> to connect two event channels was moved from a test
+<P>The <TT>Gateway</TT> to connect two event channels was moved from a test
 to the library. The corresponding test (<TT>EC_Multiple</TT>) has been
-expanded and improved.</LI>
+expanded and improved.
+</P>
+</LI>
 
 <LI>
-The user can register a set of <TT>EC_Gateways</TT> with the <TT>EventChannel</TT>
+<P>The user can register a set of <TT>EC_Gateways</TT> with the <TT>EventChannel</TT>
 implementation, the event channel will automatically update the subscription
-list as consumers subscribe to the EC.</LI>
+list as consumers subscribe to the EC.
+</P>
+</LI>
 
 <LI>
-The code for consumer and supplier disconnection was improved and seems
-to work without problems now</LI>
+<P>The code for consumer and supplier disconnection was improved and seems
+to work without problems now
+</P>
+</LI>
 
 <LI>
-The <TT>Event_Service</TT> program creates a collocated <TT>Scheduling
-Service</TT> this works around a problem in the ORB when running on multiprocessor.</LI>
+<P>The <TT>Event_Service</TT> program creates a collocated <TT>Scheduling
+Service</TT> this works around a problem in the ORB when running on
+multiprocessor.
+</P>
+</LI> 
 
 <LI>
-Startup and shutdown were revised, the event channel shutdown cleanly now.</LI>
+<P>Startup and shutdown were revised, the event channel shutdown
+cleanly now.
+</P>
+</LI> 
 
 <LI>
-Added yet another example (<TT>$TAO_ROOT/orbsvcs/tests/EC_Throughput</TT>),
+<P>Added yet another example
+(<TT>$TAO_ROOT/orbsvcs/tests/EC_Throughput</TT>),
 this one ilustrate how to use the TAO extensions to create octet sequences
 based on CDR streams, without incurring in extra copies. This is useful
 to implement custom marshalling or late dermashalling of the event payload.
 Future versions of the test will help measuring the EC throughput, hence
-the name.</LI>
+the name.</P>
+</LI>
 </UL>
 
 </BODY>
diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html
index 2353504dfa9..483f351604d 100644
--- a/TAO/docs/releasenotes/index.html
+++ b/TAO/docs/releasenotes/index.html
@@ -584,6 +584,8 @@ Time Service Specification.</A>
 <H3><A NAME="ec">CORBA Event Service</A></H3>
 
 <H4>
+<!-- @@ Pradeep: can you find an URL that points to the OMG website? -->
+<!-- IMHO it will look more official like that. -->
 Last Updated: Sat Jan&nbsp; 2 01:17:33 CST 1999</H4>
 Point of contact: <A HREF="mailto:pradeep@cs.wustl.edu">Pradeep Gore</A>
 <P>The COS compliant Event Service implements the <A HREF="http://siesta.cs.wustl.edu/~coryan/Docs/formal/97-12-11.pdf">Event
@@ -595,7 +597,7 @@ Features in this release:</H3>
 <UL>
 <LI>
 The Event Channel (<TT>$TAO_ROOT/orbsvcs/orbsvcs/CosEvent</TT>) supports
-the <TT>push </TT>style event&nbsp; communication.</LI>
+the <TT>push </TT>style event communication.</LI>
 
 <LI>
 A simple test (<TT>$TAO_ROOT/orbsvcs/tests/CosEC_Basic</TT>) demonstrates
@@ -608,12 +610,13 @@ Current Work:</H3>
 <UL>
 <LI>
 <TT>Event Service</TT>: The Event Service will create an event channel
-and register it with the naming service, Push style consumers and producers</LI>
+and register it with the naming service, Push style consumers and
+producers</LI> 
 
 <BR>can then connect to the service and send /receive events.
 <LI>
 <TT>CosEC_Multiple</TT>:&nbsp; This test demonstrates how multiple CosEC's
-connect to one RtEC and how multiple consumers and producers exchange<BR>
+connect to one RtEC and how multiple consumers and producers exchange
 events in this configuration.</LI>
 
 </UL>