-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Namespace prefix support #1792
base: main
Are you sure you want to change the base?
Namespace prefix support #1792
Conversation
PR missing one of the required labels: {'internal', 'bug', 'enhancement', 'dependencies', 'documentation', 'new feature', 'breaking-change'} |
Btw this needs to be tested also with rmw_zenoh, idea on how to do it? |
}; | ||
|
||
pub(crate) static KE_UHLC: &keyexpr = ke!("uhlc"); | ||
#[zenoh_macros::unstable] | ||
kedefine!( | ||
pub(crate) ke_liveliness: "@adv/${entity:*}/${zid:*}/${eid:*}/${meta:**}/@/${remaining:**}", | ||
pub(crate) ke_liveliness: "${remaining:**}/@adv/${entity:*}/${zid:*}/${eid:*}/${meta:**}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the current form a keyexpr is transformed from a/b/c
to @foo/prefix/a/b/c
.
Would it make sense to simply invert the order to a/b/c/@foo/prefix
?
Would it make the whole namespace prefix logic simpler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the comment, In this PR it is indeed supposed to be transformed into a/b/c/@foo/prefix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarification. I see the intended behaviour was introduced by #1780 and integrated in this PR. I was momentarily misled by this PR title.
Maybe @evshary have some ideas, otherwise I suppose we would need to create dedicated branches on zenoh-c and zenoh-cpp. |
81fbc9e
to
e002c6a
Compare
The implementation LGTM. However it should be tested with |
Sister PRs may be needed for bindings, as just changing the branch makes zenoh-c CI to fail: https://github.com/eclipse-zenoh/zenoh-c/actions/runs/13541109439/ |
I did run some tests on my machine:
and I got: current main 8 bytes payload, routed:
this branch 8 bytes payload, routed, namespace is :
so a few hundreds k/msgs/s are lost may need to re-run the test on a better machine, instead of the laptop |
Namespace prefix support
Supersedes #1772.
Includes #1780.
Related PRs to account for api changes:
eclipse-zenoh/zenoh-c#930
eclipse-zenoh/zenoh-cpp#417