summaryrefslogtreecommitdiff
path: root/TAO/docs/releasenotes/index.html
diff options
context:
space:
mode:
Diffstat (limited to 'TAO/docs/releasenotes/index.html')
-rw-r--r--TAO/docs/releasenotes/index.html786
1 files changed, 0 insertions, 786 deletions
diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html
deleted file mode 100644
index e103be67a88..00000000000
--- a/TAO/docs/releasenotes/index.html
+++ /dev/null
@@ -1,786 +0,0 @@
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]">
- <TITLE>TAO Release Information and TODO List</TITLE>
-</HEAD>
-<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
-<!-- $Id$ -->
-<CENTER>
-<HR></CENTER>
-
-<CENTER>
-<H3>
-Release Information for The ACE ORB (TAO)</H3></CENTER>
-Information is available on the following topics related to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/VERSION">current
-release</A> of <A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A>:
-<UL>
-<LI>
-<A HREF="orbcore.html">ORB Core</A></LI>
-
-<LI>
-<A HREF="#idl">IDL Compiler</A></LI>
-
-<LI>
-<A HREF="#poa">Portable Object Adapter</A></LI>
-
-<LI>
-<A HREF="#nservices">CORBA Naming Service</A></LI>
-
-<LI>
-<A HREF="ec.html">CORBA Event Service</A></LI>
-
-<LI>
-<A HREF="#tservices">CORBA Trading Service</A></LI>
-
-<LI>
-<A HREF="#pservices">CORBA Property Service</A></LI>
-
-<LI>
-<A HREF="#cservices">CORBA Concurrency Control Service</A></LI>
-
-<LI>
-<A HREF="#logging">CORBA Logging Service</A></LI>
-
-<LI>
-<A HREF="#implrepo">Implementation Repository</A></LI>
-
-<LI>
-<A HREF="#av">CORBA Audio/Video Control Service</A></LI>
-
-<LI>
-<A HREF="#apps">Test &amp; Example Applications</A></LI>
-
-<LI>
-<A HREF="#ace">ORB-related ACE Changes</A></LI>
-
-<LI>
-<A HREF="#dove">The DOVE Demo</A></LI>
-
-<LI>
-<A HREF="#forwarding">Location forwarding</A></LI>
-
-<LI>
-<A HREF="#leader">Global resources and leader-follower model</A></LI>
-
-<LI>
-<A HREF="#locate">Locate requests</A></LI>
-<LI>
-
-<A HREF="TODO.html">Our TODO list</A></LI>
-</UL>
-
-A complete list of all modifications to TAO is available in the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/ChangeLog">ChangeLog</A>.
-
-<P>&nbsp;
-<HR><!--#include virtual="orbcore.html" -->
-<HR>
-<H3>
-<A NAME="idl"></A>IDL Compiler</H3>
-Point of contact: <A HREF="mailto:gokhale@cs.wustl.edu">Aniruddha Gokhale</A>
-
-<P>Current status: (As of July 31st, 1998.)
-<UL>
-<LI>
-Anonymous arrays inside structs are supported. However, they are not yet
-supported inside unions.</LI>
-
-<LI>
-Perfect Hashed Operation Lookup Strategy has been added to the IDL Compiler.
--P flag to the&nbsp;<tao_idl>enables the perfect hased lookup strategy.
-This strategy uses <A HREF="http://www.cs.wustl.edu/~schmidt/gperf.ps.gz">GPERF</A>,
-the GNU's Perfect Hash Function Generator written by Dr.Douglas C. Schmidt.
-Right now, GPERF works only on Solaris. Any work on porting GPERF to other
-platforms will be highly appreciated.&nbsp;</L1></LI>
-
-<LI>
-Support for Arrays is refined in terms of the code generated for parameters
-inside stubs and skeletons.</LI>
-
-<LI>
-Significantly improved the support for unions. The default case is yet
-to be handled.</LI>
-
-<LI>
-Added support for Arrays. Right now, support for typedefed arrays is in.
-Still needs testing.</LI>
-
-<LI>
-Added support for TIE classes. If the interfaces are defined inside modules,
-then the TIE class and its code gets generated inside a conditional macro.
-For platforms that support namespaces, this macro will allow these TIE
-classes else they get commented out. The reason to do this is because nested
-templates have problems on most compilers.</LI>
-
-<LI>
-The &lt;&lt;= and >>= operators for user-defined types are now generated.</LI>
-
-<LI>
-Completely redesigned the IDL compiler using the Visitor patterns. Many
-incomplete issues have been resolved. These include support for "sequence
-of typecodes", passing object references as in, inout, and out parameters.
-Code generation for sequences is also properly handled i.e., for a named
-sequence such as "typedef sequence&nbsp;<char>CharSeq;", we now generate
-a new class (and hence a type) called "class CharSeq". Arrays are still
-being worked out and will be done soon. An important difference in the
-generated code is that the skeletons now use a table driven approach very
-similar to the stubs.</LI>
-
-<LI>
-Support for the "native" keyword added.</LI>
-
-<LI>
-Introduced tests for object references to TAO. Still incomplete.</LI>
-
-<LI>
-Param_Test example is able to test string sequences, fixed structs, variable
-sized structs and nested structs</LI>
-
-<LI>
-Param_Test test suite can now test fixed structs and string sequences.This
-needed bug fixes to TAO ORB core.</LI>
-
-<LI>
-A new test to test all the parameter passing modes for a number of data
-types has been added. At this point in time, it tests primitive types and
-strings. Other tests will be added. Bugs discovered thru these tests have
-been fixed.</LI>
-
-<LI>
-Very preliminary support for arrays. Not working yet.</LI>
-
-<LI>
-Many bugs associated with stub generation fixed. This included support
-for return values that are variable sized IDL types. Unions improved.</LI>
-
-<LI>
-Support for sequences of strings and object references added. However,
-it is not tested yet so there may be some bugs. We should have these fixed
-in a day or so.</LI>
-
-<LI>
-Support for handling exceptions added. TAO does not use direct C++ exceptions.
-Instead it uses the CORBA::Environment based approach.</LI>
-
-<LI>
-Sequences as out parameters have been tested in the IDL_Cubit example.
-A test suite is currently being built to test all the parameter passing
-modes on a variety of IDL data types.</LI>
-
-<LI>
-Support for attributes completed. Not tested yet.</LI>
-
-<LI>
-The problem of incorrect code generation for typedefs defined in an imported
-file is resolved.</LI>
-
-<LI>
-Problems when interfaces use single or multiple inheritance solved. The
-problem was with the demultiplexing code, the generated operation tables,
-and the dispatching mechanism. We are currently testing this with the Event
-Channel code.</LI>
-
-<LI>
-The problems arising due to public virtual inheritance when casting from
-an interface class to CORBA::Object_ptr has been solved. We do this casting
-inside the stubs/skeletons rather than first converting an interface class
-pointer to a void*, storing it in an Any, and casting it to CORBA::Object_ptr
-in the encode/decode methods. The casting inside the stubs/skeletons work
-because the compiler has knowledge of both types.</LI>
-
-<LI>
-The compiler generates correct code for COSS Naming service and it runs
-properly. Correct code also gets generated for the Event Channel program</LI>
-
-<LI>
-Include files are handled properly. So are the definitions used inside
-the include files that are used in the currently parsed files.</LI>
-
-<LI>
-IN, INOUT, and OUT object reference parameters are now supported properly.
-We think the same approach should work for sequences, structs, and unions.</LI>
-
-<LI>
-Many IDL constructs supported including primitive types, typedefs, sequences,
-structures, and unions.</LI>
-
-<LI>
-Generates C++ stubs and skeletons that use TAO's <A HREF="http://www.cs.wustl.edu/~schmidt/HICSS-97.ps.gz">interpretive
-IIOP protocol engine</A>.</LI>
-
-<LI>
-Generated code closely follows the C++ Mapping specified in the POA Specification
-(ORBOS/97-05-15).</LI>
-
-<LI>
-Support dynamic libraries on NT, i.e., marking classes for DLL export was
-added. Two backend options control the name of the export macro, and the
-name of an extra include file were the macro is defined; the options are
-<TT>-Wp,export_macro=MACRO_NAME</TT> <TT>-Wp,export_include=INCLUDE_NAME</TT>.</LI>
-
-<LI>
-The IDL compiler generates now source code for sequences. The user has
-now the option to use these generated sequence classes or to use, as up
-to now, the template instatiation. If TAO_LACKS_TEMPLATE_SPECIALIZATION
-is defined, then template instantiation will be used, else not. The reason
-for this was, that some C++ compilers did not support template instantiation
-properly and sequences were based on templates. The generated source code
-is mainly contained in the generated header file directly in the class
-declaration.</LI>
-</UL>
-Known bugs/unimplemented constructs:
-<UL>
-<LI>
-Generation of Managed types must somehow be moved to the ORB Core</LI>
-
-<LI>
-We need support for ``TIEs'' (i.e., the object form of the Adapter pattern).</LI>
-
-<LI>
-TypeCode generation for multidimensional arrays and indirected typecodes
-is still a problem.</LI>
-
-<LI>
-Unions with default cases yet to be handled</LI>
-
-<LI>
-Deal with names in the IDL definition that are C++ keywords.</LI>
-
-<LI>
-IDL is case-insensitive. However, it looks like our front-end is case-sensitive.
-Thanks to Anil Gopinath (anil@ittc.ukans.edu) for pointing this out.</LI>
-
-<LI>
-tao_idl generates code for a *.idl file only inside the directory where
-the *.idl resides. However, it may be required to generate code elsewhere
-i.e., in the directory where the compiler was invoked. Thanks to Tom Richards
-(tomr@MCMEnterprise.com) for this suggestion.</LI>
-</UL>
-Future work:
-<UL>
-<LI>
-Need to relocate the various libraries used by the IDL compiler out of
-the ACE directory. Having them here can cause problems when working with
-multiple versions of TAO and a single version of ACE.</LI>
-
-<LI>
-Improve IDL compiler to generate compiled form of stubs/skeletons.</LI>
-
-<LI>
-Fix bugs in the SunSoft IDL front-end we've uncovered. These primarily
-include support for Unions.</LI>
-
-<LI>
-Add command line options to TAO IDL. These options will decide what strategy
-to use for operation name demultiplexing. Another option may decide whether
-to use the interpretive IIOP engine or generate compiled stubs/skeletons.</LI>
-
-<LI>
-Use <A HREF="http://www.cs.utah.edu/projects/flux/flick/">Flick</A> (from
-the University of Utah) to generate compiled stubs.</LI>
-
-
-<P>Goal is to measure the code size of the interpretive stubs generated
-by TAO IDL compiler <I>vs</I> code size of compiled stubs. Then compare
-the performance of each. We want to prove the thesis that TAO IDL compiler
-generated interpretive stubs have a small code size, yet are comparable
-in performance (or slightly less) than compiled stubs. Hence, it will be
-useful for small distributed equipment such as handsets, PDAs, etc.
-
-<P>In doing the above, improvements to the IIOP protocol engine in terms
-of size/performance/determinism will be made.
-<LI>
-Tweak the IDL compiler to generate code that's more easily integrated back
-into the ORB Core, e.g., POA, etc. This will depend largely on our ability
-to generalize the changes necessary to generated code.</LI>
-</UL>
-
-<LI>
-The generated sequence classes should not be generated per sequence, but
-per type and parent scope. Which means, that the overhead of having the
-source code generated serveral times should be reduced. To do this, an
-extra pass over the internal representation of the IDL file has to be done.&nbsp;
-<HR></LI>
-
-<H3>
-<A NAME="poa"></A>Portable Object Adapter</H3>
-Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>
-
-<P>Current Status:
-<UL>
-<LI>
-TAO fully supports the POA spec. This section will carry updates as available.</LI>
-</UL>
-Known issues:
-<DL>
-<DT>
-<I>Support for collocation is not complete.</I></DT>
-
-<DD>
-If an object which should be collocated is created via <TT>string_to_object</TT>,
-it is created as a remote object rather than collocated.</DD>
-</DL>
-Critical work:
-<UL>
-<LI>
-None.</LI>
-</UL>
-Future work:
-<UL>
-<LI>
-Determine the degree to which we will support the full semantics of remote
-objects on a collocated object. The spec mandates that collocated object
-should behave <I>exactly</I> like remote objects, but that means that request
-will have to be queued rather than calling a method directly, and this
-could be hazardous to our quest for real-time ORB status.</LI>
-
-<LI>
-Provide extensions of the specification to ensure real-time delivery of
-messages.</LI>
-</UL>
-
-<HR><!--#include virtual="ec.html" -->
-<HR>
-<H3>
-<A NAME="nservices"></A>CORBA Naming Service</H3>
-Point of contact: <A HREF="mailto:sergio@cs.wustl.edu">Sergio Flores-Gaitan</A>
-and <A HREF="mailto:marina@cs.wustl.edu">Marina Spivak</A>
-
-<P>Current status (as of Feb 27th):
-<UL>
-<LI>
-The Naming Service implementation is complete.</LI>
-</UL>
-Future work:
-<UL>
-<LI>
-Currently the bindings are stored as a table in memory. Future work will
-include a persistent database to store the bindings.</LI>
-
-<LI>
-Replication of the bindings to other Naming Service's currently running.
-It will probably be modeled after the LDAP Multi-Master Replication Protocol.
-For more information on this replication protocol please read <A HREF="ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-02.txt">LDAP
-Multi-Master Replication Protocol</A></LI>
-</UL>
-For general documentation on the Naming Service please read <A HREF="ftp://www.omg.org/pub/docs/formal/97-07-12.pdf">The
-Naming Service Specification</A>.
-
-<P>
-<HR>
-<H3>
-<A NAME="tservices"></A>CORBA Trading Service</H3>
-Point of contact: <A HREF="mailto:sbw1@cs.wustl.edu">Seth Widoff</A>
-
-<P>The TAO Trading Service is a transient implementation of the COS Trading
-Service speficiation that meets the Linked Trader conformance criteria
---- it implements the <TT>Lookup</TT>, <TT>Register</TT>, <TT>Admin</TT>,
-and <TT>Link</TT> interfaces, but not the <TT>Proxy</TT> interface. Notably,
-the TAO trader supports the following features:
-<UL>
-<LI>
-Multithreaded operation;</LI>
-
-<LI>
-Trader federations and distributed queries;</LI>
-
-<LI>
-Dynamic properties;</LI>
-
-<LI>
-Modifiable properties;</LI>
-
-<LI>
-All policies described in the specification;</LI>
-
-<LI>
-Preference sorting;</LI>
-
-<LI>
-Service type inheritance hierarchies and subtype searching.</LI>
-</UL>
-<A HREF="trader.html">Trading Service documentation</A> is also available.
-
-<P>Future Work:
-<UL>
-<LI>
-The Proxy Interface.</LI>
-
-<LI>
-Persistent storage of service types and offers.</LI>
-</UL>
-For general documentation of the Trading Service, please read <A HREF="http://www.omg.org/corba/sectrans.htm#trader">The
-Trading Service Specification.</A>
-
-<P>
-<HR>
-<H3>
-<A NAME="pservices"></A>CORBA Property Service</H3>
-Point of contact: <A HREF="mailto:alex@cs.wustl.edu">Alexander Babu Arulanthu</A>
-
-<P>Current status (as of May&nbsp; 02, 1998)
-<BR>&nbsp;
-<BR>All the interfaces of this service have been implemented.&nbsp; Please
-go through the&nbsp; test examples at&nbsp; $TAO/orbsvcs/tests/CosPropertyService.&nbsp;
-Property Service is&nbsp; now used by the AVStreams that is currently being
-developed for TAO. More testing is being done.
-
-<P>For general documentation of the Property Service, please read <A HREF="http://www.omg.org/corba/sectrans.htm#prop">The
-Property Service Specification.</A>
-
-<P>
-<HR>
-<H3>
-<A NAME="implrepo"></A>Implementation Repository</H3>
-Point of contact: <A HREF="mailto:brunsch@cs.wustl.edu">Darrell Brunsch</A>
-
-<P>Current status (as of July 23, 1998)
-
-<P>Here is a brief list of my goals (and the dates completed). For more
-information, please see the <A HREF="../implrepo.html">Implementation Repository
-documentation</A>.
-<UL>
-<LI>
-Create the base test client and server programs [7/17]</LI>
-
-<LI>
-Add an IR that forwards server requests [7/23]</LI>
-
-<LI>
-Have the server register its IOR with the IR</LI>
-
-<LI>
-Have the server exit after every call, so it is restarted each time</LI>
-
-<LI>
-Add the ping object to the server</LI>
-
-<LI>
-Add in shutdown calls to test ping objects</LI>
-
-<LI>
-Change IOR format</LI>
-
-<LI>
-Add in support for server names</LI>
-
-<LI>
-Make the IR forward any request</LI>
-
-<LI>
-Add another server</LI>
-</UL>
-Other goals:
-<UL>
-<LI>
-Implement the IDL Interface for the IR</LI>
-
-<LI>
-Move this stuff into the POA</LI>
-
-<LI>
-Multiple Profiles</LI>
-
-<LI>
-POA extension</LI>
-
-<LI>
-Persistence</LI>
-</UL>
-Future Goals:
-<UL>
-<LI>
-TAO client-side optimization with restarted servers</LI>
-
-<LI>
-Server security (checksums)</LI>
-
-<LI>
-Helper Application</LI>
-
-<LI>
-Federation of IRs</LI>
-
-<LI>
-DLLs</LI>
-</UL>
-
-<HR>
-<H3>
-<A NAME="cservices"></A>CORBA Concurrency Control Service</H3>
-Point of contact: <A HREF="mailto:tworm@cs.wustl.edu">Torben Worm</A>
-
-<P>Current status (as of May 3rd):
-<UL>
-<LI>
-A simple version of the concurrency service has been implemented, i.e.
-a version without transactions. It is currently being tested.</LI>
-</UL>
-Future Work:
-<UL>
-<LI>
-Implementation of the Concurrency Control Service with transactions</LI>
-</UL>
-For general documentation of the Concurrency Control Service, please read
-<A HREF="http://www.omg.org/corba/sectrans.htm#concur">The Concurrency
-Control Service Specification.</A>
-
-<P>
-<HR>
-<H3>
-<A NAME="logging"></A>CORBA Logging Service</H3>
-Point of contact:&nbsp; <A HREF="mailto:mjb2@cs.wustl.edu">Matt Braun</A>
-
-<P>Current status (as of August 4'th):
-<UL>
-<LI>
-The basic logging service has been implemented. It can log basic messages
-from multiple clients. It is currently in the testing stage.</LI>
-</UL>
-Future work:
-<UL>
-<LI>
-&nbsp;Add increased functionality. Requests and suggestions are welcome.</LI>
-</UL>
-&nbsp;&nbsp;&nbsp;&nbsp;
-<HR WIDTH="100%">
-<H3>
-<A NAME="av"></A>CORBA Audio/Video Control Service</H3>
-Point of contact: <A HREF="mailto:sumedh@cs.wustl.edu">Sumedh Mungee</A>
-and <A HREF="mailto:naga@cs.wustl.edu">Nagarajan Surendran</A>
-
-<P>This is an implementation of the OMG spec addressing the <A HREF="http://www.cs.wustl.edu/~sumedh/research/corbaav.pdf">Control
-and Management of Audio/Video Streams</A>.
-
-<P>The audio/video streaming service has been implemented in the light
-profile. An MPEG-1 application which streams mpeg-1 video and mpeg-1 audio
-separately has been developed using the service. This application currently
-works only for Unix platforms.
-
-<P>Current Status:
-<UL>
-<LI>
-Implemented the handshake mechanism between the consumer and supplier of
-the stream.</LI>
-
-<LI>
-Implemented a simple version of the stream controller (StreamCtrl).</LI>
-
-<LI>
-Implemented the VDev and StreamEndPoint base class functionality.</LI>
-
-<LI>
-Implemented the MMDevice interface, which is a factory for StreamEndPoint
-and VDev objects.</LI>
-
-<LI>
-Implemented a mpeg-1 streaming audio/video application using the a/v service.</LI>
-</UL>
-Work in progress:
-<UL>
-<LI>
-Implementing the SFP protocol</LI>
-
-<LI>
-Integrating the mpeg-1 streaming application with the trading service.</LI>
-</UL>
-
-<HR>
-<H3>
-<A NAME="apps"></A>Test &amp; Example Applications</H3>
-Point of contact: <A HREF="mailto:naga@cs.wustl.edu">Nagarajan Surendran</A>
-
-<P>Current Status:
-
-<P>The TAO IDL_Cubit test application makes use of the Naming Service and
-the server holds a TAO_Naming_Server component.Just running server and
-client is enough to test the application.
-
-<P>The various tests in the tests/POA test the different features of the
-Portable Object Adapter interface like Explicit Activation, On Demand Activation,etc..
-
-<P>Future work:
-
-<P>Developing a one-buttoned test for all the different TAO tests similar
-to the ACE-one buttoned test.
-
-<P>MT_Cubit:
-
-<P>Current status:
-
-<P>The TAO MT_Cubit test application is meant to serve as a starting point
-for real-time tests on the TAO system. It comprises the following parts:
-<UL>
-<LI>
-<I>Server.</I> The server creates multiple CORBA objects (servants), each
-with different real-time priorities. This priority is implemented by using
-real-time thread support provided by the operating system. Thus, requests
-sent to a high-priority servant are handled by a high-priority real-time
-thread, and those sent to a lower priority servant are handled by correspondingly
-lower priority threads.</LI>
-
-<LI>
-<I>Client.</I> The client component binds to the servants, and sends a
-stream of CORBA requests to the servants. It measures the response time,
-i.e. the time taken for the request to complete successfully. In particular,
-it measures the time taken for requests sent to the high priority servant
-to complete. The volume of lower priority requests is configurable. The
-client is thus able to measure the performance of the high-priority servant
-in the presence of competition from several lower-priority servants.</LI>
-</UL>
-Clearly, if the ORB endsystem handles the priorities of the various requests
-correctly, increasing the volume of lower priority requests should not
-affect the performance seen by the higher priority requests. The application
-thus serves as a tool to measure and confirm this behavior.
-
-<P>Future work:
-<UL>
-<LI>
-Study the impacts of scheduling &amp; concurrency strategies on performance.</LI>
-
-<LI>
-Evolve into a testbed for discovering sources of performance non-determinism
-&amp; priority inversion.</LI>
-</UL>
-
-<HR>
-<H3>
-<A NAME="ace"></A>ORB-related ACE Changes</H3>
-Points of contact: <A HREF="mailto:nanbor@cs.wustl.edu">Nanbor Wang</A>
-and <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyrarli</A>
-
-<P>Recently Completed Work:
-<UL>
-<LI>
-Added special declaration to OS.h for <TT>inet_ntoa</TT> and other functions
-because VxWorks doesn't provide full argument prototypes for these library
-functions.</LI>
-
-<LI>
-The current caching connector behaves properly in the face of a non-blocking
-connect request. The "fix" is simply to not support non-blocking connects
-through the cache. When the <TT>connect()</TT> fails with <TT>EWOULDBLOCK</TT>,
-morph the error to -1 and clean up the request.</LI>
-
-<LI>
-Service handlers obtained from the caching connector are now cleaned up.
-The application needs to be able to signal that it's not using it any longer,
-and, when the application encounters an error, needs to effectively close
-down that connection for good so that a new connection can be initiated.</LI>
-
-<BR>Added the ability for a Svc_Handler to recycle itself. idle() can be
-called when the Svc_Handler is done serving a particular connection and
-can how be recycled. The Svc_Handler now also has a pointer to a recycler
-that is responsible for managing the connections. The recycler is usually
-a Cached_Connector.
-<BR>Added new class ACE_Recycling_Strategy. It defines the interface (and
-default implementation) for specifying a recycling strategy for a Svc_Handler.
-This strategy acts as a consular to the Svc_Handler, preparing it for the
-tough times ahead when the Svc_Handler will be recycled.
-<BR>Added new class ACE_NOOP_Concurrency_Strategy. It implements a no-op
-activation strategy in order to avoid calling open on a recycled svc_handler
-multiple times.
-<BR>ACE_Cached_Connect_Strategy now implements the ACE_Connection_Recycling_Strategy
-interface. This allows Svc_Handlers to cache themselves with ACE_Cached_Connect_Strategy
-when they become idle. It also allows them to purge themselves from the
-connection cache when the Svc_Handlers close down.
-<BR>Also added ~ACE_Cached_Connect_Strategy that will cleanup up the connection
-cache.</UL>
-Future work:
-<BLOCKQUOTE><I>None currently scheduled.</I></BLOCKQUOTE>
-
-<HR>
-<H3>
-<A NAME="dove"></A>The DOVE Demo</H3>
-Point of contact: <A HREF="mailto:mk1@cec.wustl.edu">Michael Kircher</A>.
-
-<P><A HREF="http://www.cs.wustl.edu/~schmidt/dove.html">DOVE</A> is
-documented in detail <A
-HREF="http://www.cs.wustl.edu/~schmidt/DOVE_and_LifeCycleService.ps.gz">online</A>.
-This discussion focuses on the following goals:<P>
-
-<UL>
-<LI>
-Have a DOVE Browser running using Java Beans as vizualization components.</LI>
-
-<LI>
-Have the Event Channel as DOVE Agent running with an Event Consumer in
-the DOVE Browser.</LI>
-
-<LI>
-Having a DOVE Management Information Base (MIB), which dumps all events
-transfered on the Event Channel into a file on persistent storage for later
-reuse.</LI>
-</UL>
-The DOVE Browser uses independent visualization components (Java Beans)
-and the Event Channel as DOVE Agent. Connections can be established between
-monitored metrics and the visualization components.
-
-<P>We have three major components: Observables (monitored metrics),
-Observers (a Java Bean for displaying the metric) and a DataHandler
-(for demultiplexing the monitored metrics to the appropriate
-Observables). Each component inherits from a base class, so that a
-certain behavior of the components can be assured for each
-component. Relationships between components are based on these base
-classes.
-
-<P>The used Java Beans are required to conform to some standards, as
-they have to support a function called "getProperty" which allows the
-DOVE Browser to determine if the vizualization capabilities of a
-specific Java Bean are sufficient to display the metric. A JavaBean is
-for example a Java Panel which shows a Graph of the delivered
-doubles. So all metrics can be displayed by this visualization
-component which can be expressed by a single double.
-
-<P>The DataHandler is connected to the Event Push Consumer (PUSH,
-because we use the push concept of the Event Service). The Event Push
-Consumer does not know what kind of data is transported. The only
-component knowing all the details about the dependencies of the
-metrics is the DataHandler. This separation allows easy extension and
-change of the demo.
-
-<P><A HREF="http://students.cec.wustl.edu/~mk1/dove.html">Object Diagrams</A>
-are available about this new concept.
-
-<P>Event Service events are used as communication between DOVE
-Applications and the DOVE Browser. The DOVE MIB analyses the event
-data field of all events and stores this information into a file. The
-event data filed is of type CORBA::Any and the DOVE MIB has no notion
-of what is conveyed in this field. So the DOVE MIB has to discover the
-content via the embedded type code information. Future work includes:
-
-<UL>
-<LI>
-Enhancing MIB functionality</LI>
-
-<LI>
-Monitoring the AV Streaming Service</LI>
-</UL>
-
-<HR>
-<H3>
-<A NAME="forwarding"></A>Location forwarding</H3>
-Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>,
-<A HREF="mailto:mk1@mk1.wustl.edu">Michael Kircher</A>.
-
-<P>For more information see <A HREF="../forwarding.html">Location forwarding</A>&nbsp;
-<HR>
-<H3>
-<A NAME="leader"></A>Global resources and leader-follower model</H3>
-Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>,
-<A HREF="mailto:mk1@mk1.wustl.edu">Michael Kircher</A>.
-
-<P>For more information see <A HREF="../leader_follower.html">Leader-follower
-model</A>&nbsp;
-<HR>
-<H3>
-<A NAME="locate"></A>Implementation of locate request</H3>
-Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>,
-<A HREF="mailto:mk1@mk1.wustl.edu">Michael Kircher</A>.
-
-<P>For more information see <A HREF="../locate_request.html">Locate request</A>&nbsp;
-<HR>
-
-<P>Back to the TAO <A HREF="../index.html">documentation index</A>.&nbsp;<!--#include virtual="/~schmidt/cgi-sig.html" -->
-</BODY>
-</HTML>