[Rock-dev] proposal: orocos.rb asynchronous api (ruby1.9)

[Alexander Duda]

On 10/18/2012 02:50 PM, Sylvain Joyeux wrote:
> On 10/18/2012 02:39 PM, Alexander Duda wrote:
>> On 10/18/2012 01:58 PM, Sylvain Joyeux wrote:
>>> On 10/18/2012 01:17 PM, Alexander Duda wrote:
>>>> First Phase (cleanup)
>>>> * name service:
>>>> * move into namespace Orocos
>>>> * add support for mixin
>>>> * add findIOR(TaskName) (this removes duplicated code)
>>> Don't get that one
>> At the moment, findByName and findByIOR are using identical code which
>> could be factored out into
>> a new method findIOR
> Really ? AFAIK, findByName directly resolves the name into a task 
> context proxy, findByIOR gives an IOR and returns a task context 
> proxy. There might be some overlap on the code, but it really cannot 
> be factored out easily.
>
It is not worth to argue about ;-) - but have a look at commit "binding 
corba: introduce findIOR" on branch proxy.

>> The reason for a module is that ruby is not supporting multiple
>> inheritance and therefore QTaskContext cannot not inherit from QObject
>> and a base class for the TaskContext. Therefore to overcome this all
>> base functionality should be factored-out into module which can be
>> included by TaskContext and QTaskContext.
> Except that IMO QTaskContext should only be accessing an underlying 
> TaskContext instance using the event-driven API, not subclass from it. 
> This way, you can have a single TaskContext object be accessed from 
> the synchronous API, the asynchronous API, Roby and the Qt API at the 
> same time. In any case, what you are proposing smells really really 
> bad to me.
I do see your point. And as we decided to not implement QTaskContext in 
C++ the base class approach should work.
(Log::TaskContext and TaskContext would inherit from this base class).


>>>> * TaskContext.new(name,options)
>>>> --> creates a new TaskContext for a remote task
>>> Can't have that, since the TaskContext can only be created if it has
>>> an underlying remote task object (i.e. a CORBA proxy in our case). I
>>> would really prefer to keep the .new private (people can't call it
>>> directly)
>> I agree, to create a TaskContext the Corba layer has to be initialized
>> but I would not add a factory function only because of that. Qt is going
>> the same way. QApplication has to be initialized before you can create
>> qt objects but you can still call Qt::Widget.new and do not have to call
>> any arbitrary factory function. Or do I miss something?
> orocos.rb does *not* create the underlying corba proxy. corba does it 
> for us when we resolve the name. Or are you proposing that 
> TaskContext.new calls Nameservice.resolve ?
TaskContext.new would only work if you know its IOR
--> TaskContext.new(name,options) was misleading it would be 
TaskContext.new(IOR,options)
--> or TaskContext.new(Nameservice.findIOR(task_name))

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