[Rock-dev] orogen_metadata's future

[Sylvain Joyeux]

orogen_metadata could have a bright future in Rock. It could be a very
good tool to remove e.g. the transformer broadcaster (yuk), easily
distribute transformer information as well as type sizes (for the MQ
transport).

It's a great idea, but currently it has not gone very far. There is
only the very basics done (the data type -- which has an issue because
it is incompatible with the CORBA IDL spec).

So ... as always with these things there's the question of whether it
should go into the next release. Janosch did put it in rock1408, but I
would rather not. Especially since we should probably rename one type
...

@Matthias: given that you are/were its biggest user, what's your point of view ?

Sylvain

[Matthias Goldhoorn]

Post by Sylvain Joyeux
orogen_metadata could have a bright future in Rock. It could be a very
good tool to remove e.g. the transformer broadcaster (yuk), easily
distribute transformer information as well as type sizes (for the MQ
transport).
It's a great idea, but currently it has not gone very far. There is
only the very basics done (the data type -- which has an issue because
it is incompatible with the CORBA IDL spec).
So ... as always with these things there's the question of whether it
should go into the next release. Janosch did put it in rock1408, but I
would rather not. Especially since we should probably rename one type
...
@Matthias: given that you are/were its biggest user, what's your point of view ?

So limes currently uses this only roughly too. The problem was that
because it's implemented as a property the calls to the metadata uses a
lot of time.
Since the metadata causes ugly config files and should be hidden in the
task-inspector. It vote for not putting it yet to the release.

A nice concept is would like to mention is the connection_tracking
(branch on orocos.rb), but unfortunately it makes the whole system
deployment 2x slower, and is also in a rough early state (no monitoring
of broken connection etc.).

I vote for putting in in the next release if the config-problem is
solved, and the metadata becomes a attribute.

Best,
Matthias

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
--
Matthias Goldhoorn
Unterwasserrobotik

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

Phone: [phone]
Fax: [phone]
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
-----------------------------------------------------------------------

[Sylvain Joyeux]

For the connection tracking: there would be a much better solution,
that's not too hard to implement, in RTT with close-to-zero overhead
*and* proper tracking. Basically, it would involve allowing to give an
arbitrary name to all connections *and* provide an API to list the
names of all the channels currently connected to a port. In Rock, we
would use the port URIs as names et voila ...

Sylvain

On Tue, Sep 9, 2014 at 5:51 AM, Matthias Goldhoorn

Post by Matthias Goldhoorn

Post by Sylvain Joyeux
orogen_metadata could have a bright future in Rock. It could be a very
good tool to remove e.g. the transformer broadcaster (yuk), easily
distribute transformer information as well as type sizes (for the MQ
transport).
It's a great idea, but currently it has not gone very far. There is
only the very basics done (the data type -- which has an issue because
it is incompatible with the CORBA IDL spec).
So ... as always with these things there's the question of whether it
should go into the next release. Janosch did put it in rock1408, but I
would rather not. Especially since we should probably rename one type
...
@Matthias: given that you are/were its biggest user, what's your point of view ?

So limes currently uses this only roughly too. The problem was that
because it's implemented as a property the calls to the metadata uses a
lot of time.
Since the metadata causes ugly config files and should be hidden in the
task-inspector. It vote for not putting it yet to the release.
A nice concept is would like to mention is the connection_tracking
(branch on orocos.rb), but unfortunately it makes the whole system
deployment 2x slower, and is also in a rough early state (no monitoring
of broken connection etc.).
I vote for putting in in the next release if the config-problem is
solved, and the metadata becomes a attribute.
Best,
Matthias

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
--
Matthias Goldhoorn
Unterwasserrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Phone: [phone]
Fax: [phone]
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
-----------------------------------------------------------------------
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev