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

Todo List

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 CORBA::LocalObject::_narrow(CORBA::Object_ptr obj ACE_ENV_ARG_DECL_WITH_DEFAULTS)
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.

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.

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_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_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::service_profile_selection(void)
Deprecated. Remove after TAO 1.2.1 is released.

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_Thread_Per_Connection_Handler::activate(long flags=THR_NEW_LWP, int n_threads=1, int force_active=0, long priority=ACE_DEFAULT_THREAD_PRIORITY, int grp_id=-1, ACE_Task_Base *task=0, ACE_hthread_t thread_handles[]=0, void *stack[]=0, size_t stack_size[]=0, ACE_thread_t thread_names[]=0)
: This probably needs to go after x.4.1

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

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?

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

TAO_TSS_RESOURCES singleton typedef should go away.

Generated on Fri Apr 2 17:38:11 2004 for TAO by doxygen1.2.18