Todo List

Class CORBA::Exception

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.

Member CORBA::LocalObject::_narrow (CORBA::Object_ptr obj)

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.

Module Intrusive list manipulation

We should implement this as a base template, something like:
template<class T> Intrusive_Node {
public:

void next (T *);
T* next () const;

private:
T* next_;
};
and use it as follows:
class TAO_Queued_Message : public Intrusive_Node<TAO_Queued_Message>
{
};

File Pseudo_VarOut_T.h

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.

Class TAO::ARDB_Refcount_Functor

Ideally, this class can be a generic class. But that requires quite a bit of cleanup within TAO to be more useful.

Member TAO::Cache_Entries_State

: see discussion in bugzilla 3024

Class TAO::details::range_checking< T, dummy >

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.

Class TAO::LocateRequest_Invocation_Adapter

Need to think what happens if the target is collocated. Looks like there are no ways to utilize the opportunity that may have been presented.

Class TAO_Acceptor

Need to rename the class as TAO_Transport_Acceptor.

Member TAO_Asynch_Queued_Message::TAO_Asynch_Queued_Message (const ACE_Message_Block *contents, TAO_ORB_Core *oc, ACE_Time_Value *timeout, ACE_Allocator *alloc, bool is_heap_allocated)

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.

Class TAO_Connector

Need to rename the class as TAO_Transport_Connector.

Member TAO_Endpoint::addr_lookup_lock_

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.

Member TAO_IIOP_Transport::send_request (TAO_Stub *stub, TAO_ORB_Core *orb_core, TAO_OutputCDR &stream, TAO_Message_Semantics message_semantics, ACE_Time_Value *max_wait_time)

These methods IMHO should have more meaningful names. The names seem to indicate nothing.

Member TAO_Leader_Follower::wait_for_event (TAO_LF_Event *event, TAO_Transport *transport, ACE_Time_Value *max_wait_time)

Document this better, split the Follower code to the TAO_LF_Follower class, we probably don't need the transport object.

Class TAO_LF_Event

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.

Class TAO_LF_Follower

Currently this class offers little abstraction, the follower loop should be implemented by this class.

Class TAO_Operation_Details

Put this in namespace TAO.

Member TAO_ORB_Core::ft_send_extended_sc_

reference to OMG issue. Default false.

Member TAO_ORB_Core::poa_current (void)

In the future this hook should change, instead of hardcoding the object we should add a "Resolver" to the ORB, so the "POACurrent" object returns a per-ORB object.

Similarly, each ORB should implement the TSS pattern to put the POA_Current_Impl in a void* slot. The current approach does decouple the POA from the ORB, but it cannot add new adapters or other components transparently.

Member TAO_ORB_Core_TSS_Resources::event_loop_thread_

The rest of the resources are not currently in use, just a plan for the future...

Class TAO_Queued_Message

Change the ORB to allocate oneway and AMI buffer from global memory, to avoid the data copy in this path. What happens if the there is no queueing? Can we check that before allocating the memory?

Member TAO_Reply_Dispatcher::connection_closed (void)=0

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.

Member TAO_Reply_Dispatcher::dispatch_reply (TAO_Pluggable_Reply_Params &params)=0

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.

Member TAO_Stub::orb_

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....

Member TAO_Transport::event_handler_i (void)=0

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.

This method has to be renamed to event_handler()

This method has to be renamed to event_handler()

Member TAO_Transport::handle_input (TAO_Resume_Handle &rh, ACE_Time_Value *max_wait_time=0)

the method name is confusing! Calling it handle_input() would probably make things easier to understand and follow!

Member TAO_Transport::handle_timeout (const ACE_Time_Value &current_time, const void *act)

In the future this function could be used to expire messages (oneways) that have been sitting for too long on the queue.

Member TAO_Transport::recache_transport (TAO_Transport_Descriptor_Interface *desc)

Ideally the following should be inline.

purge_entry has a return value, use it

Member TAO_Transport::register_handler (void)

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.

Member TAO_Transport::send_request (TAO_Stub *stub, TAO_ORB_Core *orb_core, TAO_OutputCDR &stream, TAO_Message_Semantics message_semantics, ACE_Time_Value *max_time_wait)=0

This is generic code, it should be factored out into the Transport class.

Class TimeBase::UtcT

What is exactly the range of time here? Is it [time-inacclo,time+inacchi]?

Member TimeBase::UtcT::tdf

please document