diff options
Diffstat (limited to 'TAO/docs/releasenotes/index.html')
-rw-r--r-- | TAO/docs/releasenotes/index.html | 643 |
1 files changed, 0 insertions, 643 deletions
diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html deleted file mode 100644 index d8787dfbbbe..00000000000 --- a/TAO/docs/releasenotes/index.html +++ /dev/null @@ -1,643 +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 & ORB Core</A></LI> - -<LI> -<A HREF="#idl">IDL Compiler</A></LI> - -<LI> -<A HREF="ec.html">Event Channel</A></LI> - -<LI> -<A HREF="#apps">Test & Example Applications</A></LI> - -<LI> -<A HREF="#poa">Portable Object Adapter</A></LI> - -<LI> -<A HREF="#nservices">CORBA Naming 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="#ace">ORB-related ACE Changes</A></LI> - -<LI> -<A HREF="#dove">The DOVE Demo</A></LI> - -<LI> -<A HREF="#vc">How to add IDL files into your Visual C++ projects</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 March 15th, 1998.) -<UL> -<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> -The <<= and >>= operators for user-defined types are not generated -yet.</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> - -<HR><!--#include virtual="ec.html" --> -<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="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> -<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: <p> - -<ul> - <li> The Proxy Interface. - <li> Persistent storage of service types and offers. -</ul> - - -<P>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 Mar 19, 1998) -<BR> -<BR> It is under development and testing. TAO's -AVStreams, which is currently being developed will make use of the -Property Service. The primary PropertySet interface -and the Iterator interfaces have been implemented and currently AVStreams' -test application has started using them. - -<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 March 25th): - -<UL> - <LI>The implementation of the service has been postponed until the - spec gets more clear. -</UL> - -<P>Future Work: - -<UL> - <LI>Implementation of the Concurrency Control Service. -</UL> - -<P>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: <p> - -<ul> - <li> Implemented the handshake mechanism between the consumer and - supplier of the stream. - <li> Implemented a simple version of the stream controller - (StreamCtrl). - <li> Implemented the VDev and StreamEndPoint base class - functionality. - <li> Implemented the MMDevice interface, which is a factory for - StreamEndPoint and VDev objects. -</ul> - -Work in progress: <p> - -<ul> - <li> Implementing the SFP protocol - <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> Implementing the CORBA Stream controller for the above - audio/video player -</ul> - -<HR> -<H3> -<A NAME="ace"></A>ORB-related ACE Changes</H3> -Points of contact: <A HREF="mailto:cleeland@cs.wustl.edu">Chris Cleeland</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> -Have the Event Channel as DOVE Agent running with an Event Consumer -in the DOVE Browser. -<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> -<P> -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> -<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> -</UL> -<P> -<HR> - -<H3> -<A NAME="#VC"></A>How to add IDL files into your Visual C++ projects</H3> -Point of contact: <A HREF="mailto:nw1@cs.wustl.edu">Nanbor Wang</A>. - -<P>Each IDL file generates .h, .i and .cpp files. Here is an example of -adding an IDL file named foobar.idl into a VC project. -<OL> -<LI> -Create/open the workspace. Create server project and client project if -you haven't had them ready. Add the IDL file <foobar.idl> and other -non-IDL generated files into both client and server projects.</LI> - -<LI> -Added foobarC.h, foobarC.i, foobarC.cpp, foobarS.h, foobarS.i, and foobarS.cpp -into the server project and foobarC.h, foobarC.i, and foobarC.cpp into -the client project.</LI> - -<LI> -Now open the project setting window (Project -> Setting... or just press -Alt-F7.) Select the IDL files in both client and server projects. Choose -to set the setting for "All Configuration." Make sure the "Exclude from -build" under the "General" tab is unchecked.</LI> - -<LI> -Click on the "Custom Build" tab. Add this entry as the build command for -IDL files:</LI> - -<PRE>..\..\..\TAO_IDL\tao_idl $(InputName).idl</PRE> -Notice that your absolute path to TAO_IDL may vary. -<LI> -Now add the following entries as "Output file(s)."</LI> - -<PRE> $(InputName)S.h - $(InputName)S.i - $(InputName)S.cpp - $(InputName)C.h - $(InputName)C.i - $(InputName)C.cpp</PRE> -Add only one entry in each line. -<LI> -We are all set. Click OK.</LI> - -<LI> -Add foobarC.cpp to client project and foobarC.cpp and foobarS.cpp to server -project.</LI> -</OL> -Notice that these procedures only setup the IDL compiler to perform correctly. - -<P>p.s. If anyone knows how to set a default setting in VC so we don't -need to perform these procedures every time a new project gets set up, -please let us know. Thanks. -<P> - -<HR> -<P>Back to the TAO <A HREF="../index.html">documentation index</A>. <!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> |