[Rock-dev] improvement TaskContext.get

[Alexander Duda]

On Thu, 2011-11-03 at 16:17 +0100, Sylvain Joyeux wrote:
> On 11/03/2011 03:59 PM, Alexander Duda wrote:
> > I agree that this behavior is not useful for starting components on the
> > robot but for a user interface it is a little bit different. And by the
> > way the method port is playing the same game.
> >
> > def port(name, verify = true)
> It's not meant to be a public fact. The reason lies in the blame:
> 
> ====
> allow to bypass the port existence check in TaskContext#port
> 
> This is to be used in disconnection code: someone can do a
> output_port.disconnect(input_port) while the input port does not exist 
> anymore
> to remove the dangling connection
> ====
> 
> >> I also don't like the caching behaviour ... I'm not sure of seeing all
> >> the implications of it, and that's a too important method to play that game.
> >>
> >> Here's what I would propose: implement TaskContext.find(expression)
> >> which returns nil if the task cannot be found (but no caching !).
> 
> > What's bad with caching?
> If not done properly, it can hide that things changed. In the port case, 
> you would start having a problem if the task unregisters a port and then 
> re-registers a new one with the same name. It is actually not only 
> possible, but problematic.
> 
> I think you have a point: the #port method should be refactored to (1) 
> not cache anymore and (2) still allow the disconnection behavior 
> mentioned in the blame.
> 
> > task.ping is verifying if the task is still valid. If this kind of
> > caching is a problem all scripts will run into this because they all
> > cache tasks,ports etc.
> Yep, but at least it's not hidden deep down in the framework. As I said: 
> I'm being careful here, as I'm usually very wary of caching behaviours.
> 
> > by the way the corba name service is heavily caching as well.
> ??? Where ?
the method resolve of the name service will always return the last bind 
no matter the remote object exists or not.

> In general, for the UI stuff, you should maybe consider creating a proxy 
> class. It could even handle the #connect() method to create 
> "name-to-name connections" in vizkit.
> 
> class TaskProxy
>     def initialize(task_name)
>        @__task_name = task_name
>     end
> 
>     def method_missing(m, *args, &block)
>         if @__task && !@__task.ping
>            @__task = nil
>         end
> 
>         @__task =
>            begin TaskContext.get(@__task_name)
>            rescue Orocos::NotFound
>            end
> 
>         if !@__task
>             return
>         end
>         @__task.send(m, *args, &block)
>     end
> end
That's a nice one :-). 

Alex 

-- 
Dipl.-Ing. Alexander Duda 
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3