On Thu, May 5, 2011 at 2:31 AM, Daniele Calisi <daniele.calisi@gmail.com>wrote:

> You are saying that the DEserialization method (I can do what I want with
>> the publisher, the problem exists only with the subscriber) is instantiated
>> during the building process and not dynamically at run-time (i.e., ROS uses
>> C++ templating facilities).
>>
>
Yeah:

void chatterCallback(const std_msgs::String::ConstPtr& msg)
{
  ROS_INFO("I heard: [%s]", msg->data.c_str());
}

ros::NodeHandle n;
ros::Subscriber sub = n.subscribe("chatter", 1000, chatterCallback);

Here subscribe() deduces the type of the message from the signature of the
callback.  This type is used to instantiate code that deserializes messages,
in this case of type std_msgs::String.


> This could be good for efficiency reasons (how much?), but I do not see the
>> point of not having the serializers/deserializers table.
>>
>
Of course you are welcome to construct one.


> Of course you can build a node with a publisher that uses serialization
>> method A and a node with a subscriber, for the same object, with a
>> serialization method B (e.g., a different version of the same object) and
>> things are going to fail. Unmarshalling are usually done (by Data
>> Distribution Services and some other middleware software) by checking object
>> name, version, etc. and then decide how to deserialize. Here it seems that
>> ROS can check this meta information, but only to decide if it is going to
>> use the right deserializer or not.
>>
>
I think you've got that right.  Topics only contain one type of message...
that's just the model ROS uses.


> Moreover, how subclassing is working here? If I send an object of class A
>> to a subscriber of class B : public A, what happens?
>>
>
Hmm, message types don't inherit from each other.


> I think that, since you are just receiving a stream of bytes from the
> network, it's up to the subscriber to convert that stream to what is right.
>

Yeah.  The current API establishes which converter you'll use when the
subscriber is created.


> Finally, you are always "type-converting" a stream of bytes to an object, I
> do not see the point of fearing this conversion, being that done statically
> at building time, or dynamically with an smart unmarshalling system.
>

Fearing the conversion?


>
> What am I missing here?
>
>
Not sure.

Troy