Update up-rust to 0.3.0 and bump own version to prepare for release.

[PLeVasseur]

No description provided.

[PLeVasseur]

I'm thinking that the same as outlined in @sophokles73's comment over here would have to occur here as well?

(I'll have to spend some more time reading about MQTT5 tomorrow to check on how to do this, was just getting this started)

        let ue_id = if uri.ue_id == WILDCARD_ENTITY_ID {
            "+".into()
        } else {
            format!("{:X}", uri.ue_id)
        };

[sophokles73]

I'm thinking that the same as outlined in @sophokles73's comment over here would have to occur here as well?

(I'll have to spend some more time reading about MQTT5 tomorrow to check on how to do this, was just getting this started)

In general, I also think that the same issue applies. However, MQTT's topic filters do not support matching string patterns. All you can do is match any ... If you need to filter on a more specific pattern, then it needs to be done in the message consumer.

[PLeVasseur]

Okay. So does that limitation of MQTT5 mean the logic should reflect CY's code prior to his update, i.e. + if entity type is wild carded or otherwise the exact ue_id?

I think that'd be a limitation we should write in the MQTT5 transport spec then right?

[PLeVasseur]

Maybe another way to put this -- if we wanted to support this behavior perhaps we should have two distinct segments in the MQTT topic then, one for entity id and one for entity type? I would think a divergence in ability to listen would not be preferable between the transports, right?

[sophokles73]

Maybe another way to put this -- if we wanted to support this behavior perhaps we should have two distinct segments in the MQTT topic then, one for entity id and one for entity type? I would think a divergence in ability to listen would not be preferable between the transports, right?

From the top of my head I would agree with that assessment. I will need to dig a little deeper into the MQTT transport spec, though.

[evshary]

Maybe another way to put this -- if we wanted to support this behavior perhaps we should have two distinct segments in the MQTT topic then, one for entity id and one for entity type? I would think a divergence in ability to listen would not be preferable between the transports, right?

In fact, I also considered this before, but I finally decided to make the structure of UUri similar to other protocols. If you decide to do so, I might want to do a similar thing on Zenoh, too.

Add some illustrations from Zenoh, $* is less performant than *