diff options
Diffstat (limited to 'TAO/docs/releasenotes/index.html')
| -rw-r--r-- | TAO/docs/releasenotes/index.html | 494 |
1 files changed, 0 insertions, 494 deletions
diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html deleted file mode 100644 index cf594675b63..00000000000 --- a/TAO/docs/releasenotes/index.html +++ /dev/null @@ -1,494 +0,0 @@ -<HTML> -<HEAD> - <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> - <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (X11; I; Linux 2.0.30_SMP i686) [Netscape]"> - <TITLE>TAO Release Information and TODO List</TITLE> -</HEAD> -<BODY TEXT="#000000" BGCOLOR="#FFFFFF"> -<!-- $Id$ --> -<CENTER> -<HR> -<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="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="#eventchannel">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="#ace">ORB-related ACE Changes</A></LI> - -<LI> -<a href="#vc">How to add IDL files into your Visual C++ projects</a> -</UL> - -<!--#include virtual="/~schmidt/ACE_wrappers/TAO/docs/releasenotes/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 Dec 31st, 1997.) - <UL> - <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> - 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> - - </UL> - - <P> Known bugs/unimplemented constructs: - <UL> - <LI> Some of the known bugs/incomplete tasks are: - <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> - </LI> - </UL> - - Future work: - <UL> - - <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> - - <LI>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.</LI> - - <LI>In doing the above, improvements to the IIOP protocol - engine in terms of size/performance/determinism will be - made.</LI> - </UL> - -<HR> -<H3> -<A NAME="eventchannel"></A>Real-time Event Channel</H3> -Point of contact: <A HREF="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</A> - -<P>Current status: -<UL> -<LI> -The current Event Channel is working on TAO, -the Scheduling Service still has some problems, -apparently related to the IDL compiler.</LI> - -<LI> -The configuration runs can be done even on the distributed scenario, using -the Real-time "Scheduling Service", which now has an IDL interface.</LI> - -<LI> -At run-time (no config runs) there is no need to use the Real-time Scheduling -Service, a faster, collocated implementation for the service is available. -Obviously the information is generated on the config runs and linked into -the program. Unfortunately the schedule information cannot be -downloaded from the service right now.</LI> - -<LI> -TAO <A HREF="#nservices">Naming Service</A> is used to locate the various -services: the Event Channel itself, the Scheduling Service, etc.</LI> - -</UL> -Future work: -<UL> - -<LI> -When several suppliers are consumers are distributed over the network -it could be nice to exploit locality and have a separate Event -Channel on each process (or host). -Only when an event is required by some remote consumer we need to send -it through the network. - -The basic architecture to achieve this seems very simple, -each Event Channel connects as another supplier to its peers, -providing a "merge" of its (local) suppliers QoS as its own QoS -specification, -the channel also registers as a consumer, -using an analogous QoS, this time looking at its consumers. - -It is not clear how to avoid event looping and how to propagate the -QoS yet, -we plan to build some experiments on this scenario, -hand crafting the QoS if necessary and evolve from there.</LI> - -<LI> -We should be able to download the schedule to the interested parties, -without need for a separate link phase. This will simplify and -speed up the developing cycle, -but requires a (small) amount of dynamic memory allocation. -It could be interesting to "save" the schedule computation in some -persistent form, so startup cost are lower too.</LI> - -</UL> -<P>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>. - -The current distribution has just one test program for the Event -Service, below are the basic instructions to run it:</P> - -<OL> -<LI> Compile everything under <CODE>$TAO_ROOT/orbsvcs</CODE>, this - needs, obviously, <CODE>$TAO_ROOT/tao</CODE> and - the IDL compiler in <CODE>$TAO_ROOT/TAO_IDL</CODE>.</LI> - -<LI> Run the naming service, the scheduling service, the event service - and the test in - <CODE>$TAO_ROOT/TAO/orbsvcs/tests/Event_Latency</CODE>; - remember to give a different port to each one, - using the <CODE>-ORBport</CODE> option.</LI> - -<LI> If you want real-time behavior on Solaris you may need to run - these programs as root; on the other hand, this particular - example really has no priority inversion, since only one - thread runs at a time.</LI> - -</OL> - -<HR> -<H3> -<A NAME="apps"></A>Test & Example Applications</H3> -Point of contact: <A HREF="mailto:sumedh@cs.wustl.edu">Sumedh Mungee</A> - -<P>Current status: - -<P>The TAO 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. <P> - -<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> -The POA implementation is almost complete. The next step is the ORB -Core / POA / IDL compiler integration. Estimated deadline for this is -December 22, 1997. -</UL> -Critical work: - -<UL> -<LI> -Re-generate win32 project files with new file names.</LI> - -<LI> -Add resolve_initial_references() to resolve the "RootPOA" entry.</LI> -</UL> - -Future work: -<UL> -<LI> -Mostly compliant with the <A HREF="http://siesta.cs.wustl.edu/~cleeland/tao/POA.pdf">ORB -Portability Specifications [orbos/97-05-15]</A> published by OMG.</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> - -<P>Current status (as of Dec 10th): -<UL> -<LI> -The Naming Service implementation is complete.</LI> -</UL> - -<P>Known problems: -<UL> -<LI> -The bind_new_context() call is not working correctly. This is getting looked at and will be resolved soon. -</LI> -</UL> - -<P>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> -</UL> - -<P>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>. - - -<!--#include virtual="/~schmidt/ACE_wrappers/TAO/docs/releasenotes/trader.html" --> -<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 <code>inet_ntoa</code> - 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 - <code>connect()</code> fails with <code>EWOULDBLOCK</code>, - 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. <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. </li> - - - </UL> - - <P>Future work: - - <blockquote> - <em>None currently scheduled.</em> - </blockquote> - -<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>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>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>Click on the "Custom Build" tab. Add this entry as the - build command for IDL files: - <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)." <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>Add foobarC.cpp to client project and foobarC.cpp and - foobarS.cpp to server project. - </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. -</BODY> -<hr><P> -Back to the TAO <A HREF="../index.html">documentation index</A>. -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</HTML> |