Main Page Namespace List Class Hierarchy Alphabetical List Compound List File List Namespace Members Compound Members File Members Related Pages

## Todo List

Member TAO_Asynch_Queued_Message::TAO_Asynch_Queued_Message(const ACE_Message_Block *contents, ACE_Allocator *alloc=0, int is_heap_allocated=0)
  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.

Member TAO_ClientRequestInterceptor_Adapter::send_request(TAO_ClientRequestInfo_i *ri ACE_ENV_ARG_DECL)
  The "send_poll()" and "receive_other()" (for AMI) PortableInterceptor interception points are missing.

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.

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.

Class TAO_ORB_Core_Auto_Ptr
  TAO_ORB_Core_Auto_Ptr should be renamed to TAO_ORB_Core_var since the ORB Core is reference counted.

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_Queued_Message::next(void) const
  : 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> { };

Member TAO_ServerRequest::request_service_info(void)
  This two methods should go away.

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

Class TAO_Sync_Strategy
  The class name (Sync_Strategy) is inherited from the policies (SyncScopePolicy), but Queueing_Strategy probably captures its intent better. It should be changed in a future revision of the ORB.

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.

Member TAO_Transport::handle_input_i(TAO_Resume_Handle &rh, ACE_Time_Value *max_wait_time=0, int block=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::register_handler(void)
  : shouldn't this be automated?

Member TAO_Transport::register_handler_i(void)=0
  : 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, int 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

Member TAO_TSS_RESOURCES
  TAO_TSS_RESOURCES singleton typedef should go away.