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

[Alexander Duda]

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

>
>>         * add support for multiple corba name services
> Which in the end means "support for abitrary numbers of name services".
Yes

>
>>     * Orocos::TaskContext
>>         * factor out base functionality (mixin)
>
> I don't understand what you want to put in modules. Don't use mixins 
> if they are not really needed. Usually, base classes do the trick just 
> fine.
>
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.

>>         * cleanup initialize (scattered across 3 places 
>> get,do_get,initialize,NameService.resolve)
>>         * fix Nameserive.resolve(name) (returns half initialized object)
> Aren't the two points the same ?
Yes, one would also fix two
>
>
>>         * 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?

>
>>               * Nameservice.reslove(name,options)
>>                   -->  uses a name service to find a task context. 
>> Does not necessarily
>>                          create a new one. This should be the default 
>> way!
> I would prefer keeping .get instead of .resolve
resolve is the name of the function right now, but I do not have any 
preferences
>
>>               * TaskContext.get(name,process)
>>                   -->  same as Nameservice.resolve and could be 
>> removed at some point
>>         * add support for prefixing / namespace


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