diff options
Diffstat (limited to 'TAO/docs/releasenotes/index.html')
| -rw-r--r-- | TAO/docs/releasenotes/index.html | 587 |
1 files changed, 0 insertions, 587 deletions
diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html deleted file mode 100644 index e839736dd3c..00000000000 --- a/TAO/docs/releasenotes/index.html +++ /dev/null @@ -1,587 +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 Trader 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="#av">CORBA Audio/Video Control Service</A></LI> - -<LI> -<A HREF="#apps">Test & Example Applications</A></LI> - -<LI> -<A HREF="#ace">ORB-related ACE Changes</A></LI> - -<LI> -<A HREF="#dove">The DOVE Demo</A></LI> - -</UL> -<!--#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 June 1st, 1998.) -<UL> -<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 <<= 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 <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> -</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><P> -</UL> - -<HR> -<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>Development is complete, and testing and debugging have commenced on -the TAO Trading Service. Currently, it meets the Linked Trader conformance -requirements, in that it supports the Lookup, Register, Admin, and Link -interfaces. The Lookup interface supports subtype searching, preference -sorting, dynamic property evaluation, federated queries, and concurrent -queries as a multi-threaded servant. - -<P>The Trading Service uses the Object Space implementation of the Standard -Template Library. - -<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 02, 1998) -<BR> -<BR>All the interfaces of this service have been implemented. Please -go through the test examples at $TAO/orbsvcs/tests/CosPropertyService. -Property Service is 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="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="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>We are currently implementing the various interfaces defined in the -above spec. We are also working on building a audio/video streaming demo -that will use the above service as the control mechanism and JAWS as an -efficient transport and protocol processing framework. - -<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> -</UL> -Work in progress: -<UL> -<LI> -Implementing the SFP protocol</LI> - -<LI> -Porting the distributed audio/video player developed at <A HREF="http://www.cse.ogi.edu/~scen/Player">OGI</A> -to ACE (and in the future to JAWS)</LI> - -<LI> -Implementing the CORBA Stream controller for the above audio/video player</LI> -</UL> - -<HR> -<H3> -<A NAME="apps"></A>Test & 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 & concurrency strategies on performance.</LI> - -<LI> -Evolve into a testbed for discovering sources of performance non-determinism -& 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>DOVE is described in detail on the following site: <A HREF="http://www.cs.wustl.edu/~schmidt/dove.html">DOVE -documentation</A> - -<P>We focus on the following goals at the moment: -<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> - -<P><HR> - -<P>Back to the TAO <A HREF="../index.html">documentation index</A>. <!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> |