|Subject:||Re: [Paparazzi-devel] Paparazzi bus MQ wrapper|
|Date:||Wed, 28 Jan 2015 18:58:59 +0100|
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 changes (switching branches?). So it's mostly about having alternatives for changing theunderlying transport mechanism and interfacing with other systems.
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.
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 );
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|