|Subject:||Re: [Paparazzi-devel] Paparazzi bus MQ wrapper|
|Date:||Wed, 28 Jan 2015 15:51:51 -0300|
Hi,Felix, at the moment it's a string like ivy. It's possible to work with the message definition at the bus level,but if I understand this correctly, you'd get binary dependency and requirements to recompile the bus if amessage definition changesOf course the pprzbus should not need to be recompiled to get updated message definitions, this has to done at runtime (like giving it the message specifications), otherwise it doesn't make sense.Also implementations like ivy wouldn't need to care about that
The reason for adding the sender parameter is how I saw that the regex's were used in general. Usually there'sno filter, so the app doesn't care about the sender, but in some regex's you get a "1" for the ac_id or a"ground" at the start. The regex is pretty difficult to parse and make sense of, so I made this an explicitfunction of the API instead.
Regarding adding the sender:
I thin I would prefer it if you "simply" subscribe to a topic and not additionally filter on the sender.
In most middlewares using pub/sub you also don't have that.
Instead you usually encode the "sender" in the topic name by e.g. namspacing it...
Something like this is further away from Ivy and requires more work, but would better map to other middlewares (I'm also thinking about ROS here).
I imagine that an API call for bindings on the bus would then eventually look like this, without regex's:bind_id PprzBusBind( MsgCallback callback, const char *msg_name, const char *sender );So basically I was thinking if we shouldn't try to do something more likeSubscriber * pprz_bus_subscribe(const char *topic, MsgCallback callback);or maybe
Subscriber * pprz_bus_subscribe(const char *topic, MsgType type, MsgCallback callback);An option is probably also needed to split data arguments or not, because telemetry messages split thedata arguments into an arg list before returning, whereas the gcs and server just return the msg_name+dataas one single line.The need to distinguish between these cases is what I would like to avoid...
but would probably be a lot of work to map the purely string based Ivy approach to a message based one.
What would be nice if in the end we could "just" subscribe to topics (e.g. via redis) and get a full message back.
Meaning the client doesn't need to know messages.xml and parse that again, but can get that info either separately once from redis or get the message as a JSON object (including fields).
Also connecting ROS and mavlink to it would be great...
So basically I'm wondering how far we should go here, IMHO the benefit of just mapping the Ivy approach to e.g. redis is a bit limited...
|[Prev in Thread]||Current Thread||[Next in Thread]|