Generic TaskContext acting as gateway for remote tasks

Hi,

I have the following problem and I hope that someone can give me some
answers to my questions or recommendations how tackle it.

Situation:
The orocos components are running on a remote machine connected to a
laptop with a very slow wifi connection ( < 10 MBits) which is heavily
used by non orocos programs and might be shut-down from time to time.
The components on the laptop are non critical and are only for human
supervision. They are written in qt-ruby (single threaded) with ruby
bindings for the TaskContext therefore all blocking calls will also
block the user interface which must be avoided.

I guess a topic bases system would be better for unreliable connections
but to overcome this for corba based connections a generic TaskContext
could be used running on the laptop and dynamically proxing the hole
task interfaces of the remote tasks. This would have several benefits:
* all local TaskContexts are communicating with the generic TaskContext
which is reliable
* large timeouts without affecting the user interface
* automatically reconnect if a remote task was restarted or the
connection was broken
* the generic tasks can be used to display the same data on several
laptops without effecting the network downlink.
* the number of transmitted samples can be controlled with pulled
connections
* blocking calls (read on pulled connection, creating TaskContextProxy,
accessing nameserver) can be done from worker threads.
* can be transparently used if integrated into the tooling

I have already implemented a prototype with limited functionality but
there are still some remaining questions.

Is there any documentation explaining which of the RTT::corba method
calls are thread safe / can be called from a worker thread?
* RTT::corba::TaskContextProxy::Create?
* TaskContextProxy remote methods calls?
* read on a pulled connections?

Is there any documentation explaining how the corba connections behave
if the remote task is no longer reachable?
* is port.connected() always returning false in these cases?

How to detect that a TaskContextProxy is no longer valid?
* Do I have to call any operation on it to detect it?

Any help or suggestions are appreciated

Alex