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

[Sylvain Joyeux]

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.

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

>>> * 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 ?
-- 
Sylvain Joyeux (Dr.Ing.)
Space & Security Robotics

!!! Achtung, neue Telefonnummer!!!

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

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik 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
-----------------------------------------------------------------------