Alexandre, you're right.
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 (switching branches?). So it's mostly about having alternatives for changing the
underlying 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'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.
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 the
data arguments into an arg list before returning, whereas the gcs and server just return the msg_name+data
as one single line.
Rgds,
Gerard