[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Paparazzi bus MQ wrapper

From: Gerard Toonstra
Subject: Re: [Paparazzi-devel] Paparazzi bus MQ wrapper
Date: Wed, 28 Jan 2015 15:51:51 -0300

On Wed, Jan 28, 2015 at 2:58 PM, Felix Ruess <address@hidden> wrote:

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 a 
message definition changes 

Of 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

ah, ok, better understood now. Doing some runtime checks and potentially conversions. 
 The reason for adding the sender parameter is how I saw that the regex's were used in general. Usually there's
no 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 explicit
function 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).

In my mind the sender is not mandatory, but optional. 

What I intended with the API is to push those details of the "bus protocol" to the bus layer. From the perspective of the app, there's a message
and some sender that you want to be called back for, but it's probably better to put the details of how this travels on the bus to the
bus layer. Then, if we change our minds how it's done in the future there's no need to update the app code for bus protocol changes.
When we pass in a string like "TOPIC_NAME.1", then we make such decisions at the level of the application (as we do now with ivy).

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 like

Subscriber * 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 the 
data arguments into an arg list before returning, whereas the gcs and server just return the msg_name+data
as 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).

There's some thinking to be done here how this works in detail:
- Which format is used by applications to pass messages to the bus layer (already json? or an argument string as now?)
- What actions the bus performs on the message. Only validation (num args, type looks ok?) or also conversion to something else.
  Machines don't care about fields, so I'm not sure if it's a good idea to convert this to json for transport.
- THe actions the bus performs at the other end on receipt.
- How the message is forwarded to the application at the other end. (json?).

The class in paparazzi already does some of this work. It receives the arguments and then passes back a 
dictionary to the caller, which can refer to values by name. We can do this from a C library, but C clients do not natively
have dictionary constructs available, so we may have to pick a supporting library for that.
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...

ok, but redis is just an example. It's supposed to become a library with multiple plugins for rabbitmq,, redis and others....



reply via email to

[Prev in Thread] Current Thread [Next in Thread]