According to the OMG CORBA C++ Mapping version 1.1, the copy constructors should be moved to "protected" section in class declarations. Since the current MS Visual C++ 7.1 compiler will cause some problems to TAO's exception mechanism, we defer doing this until we drop support for MSVC++ 7.1. Maybe there is another solution, have to test that later.
Narrowing a LocalObject to a CORBA::Object is broken right now. The solution seems to be making CORBA::Object an abstract base class and create a CORBA::RemoteObject for regular object. Or, even easier, add a is_local member into CORBA::Object. I'll take the easier route for now.
There is no control on a per-sequence type basis, only on a per-underlying type basis, for example, the following two IDL sequences would get the same behavior: // IDL typedef sequence<MyStruct> MyStructSequence; typedef sequence<MyStruct> MyStructList;
There is no way to control behavior on a per-sequence basis, i.e. to have some sequences of longs checked while others are not. This is easy to fix, simply:
make all members of safety_traits non-static
have each sequence contain their own instance of safety_traits
grant users read/write access to the safety_traits of each sequence but there are footprint consequences to that approach. Until there is more demand to justify the cost, I will not implement such a change.
I'm almost sure this class will require a callback interface for AMIs sent with SYNC_NONE policy. Those guys need to hear when the connection timeouts or closes, but cannot block waiting for the message to be delivered.
This lock should be strategized so that we dont lock in single threaded configurations. It is not possible to do this now as most of the information is available in the ORB_Core which is not available here.
Implementing the Leader/Followers loop in this class, as well as the callbacks to communicate that an event has completed leads to excessive coupling. A better design would use a separate class to signal the events, that would allow us to remove the Leader/Followers logic from the ORB. However, that requires other major changes and it somewhat complicates the design.
If the connection was closed due to a CloseConnection message then we could re-issue the request instead of raising the exception, it would a matter of simply adding a boolean argument to this function.
Pluggable Messaging: this method has too many arguments, the "Right Thing"[tm] is for the Transport Object to create a "ClientReply" that encapsulates all we need to process a reply. Naturally it is possible that different messaging protocols implement different variants of such ClientReply class.
Why do we need both a reference to the ORB_Core and its ORB? It think the memory management rules for the ORB_Core changed, in the good old days it was the CORBA::ORB class who owned the ORB_Core, now it is the other way around....
Since we only use a limited functionality of ACE_Svc_Handler we could probably implement a generic adapter class (TAO_Transport_Event_Handler or something), this will reduce footprint and simplify the process of implementing a pluggable protocol.
I think this method is pretty much useless, the connections are *always* registered with the Reactor, except in thread-per-connection mode. In that case putting the connection in the Reactor would produce unpredictable results anyway.
Look into adding a template parameter to each of the templates in question that would be a trait containing the means for releasing references managed by the templates. Doing so should work around the non-dependent name issues in g++ 3.4, thus easing the requirement that this header be parsed last.
Generated on Tue Apr 14 11:25:00 2009 for TAO by