Closed evshary closed 1 month ago
Hey @evshary -- is this generally useful to include in e.g. the uAttributes spec?
That's what I had originally thought
I agree that this seems like it belongs in the UAttributes (or even better, UUri) spec. It's not zenoh specific.
It would also be really helpful to have a similar table of the allowable values for both source and sink when sending a message.
@PLeVasseur @gregmedd @sophokles73 Thanks for your suggestion. I thought it was the only issue Zenoh faced, but it seems like we can view it more generically. I've moved it to uattributes.adoc
now.
@stevenhartley The idea of the table is to distinguish message type from different source and sink resource_id
combinations. You gave a good suggestion to add use cases here, which I didn't think of before.
I've updated the table now. I think the FFFF
of the resource_id
indicates that we don't care about the value.
For the case {0, FFFF}
, it should have the same meaning as {0, [1-7FFF]}
, while {0, [8000-FFFE]}
is not valid.
However, I agree that users might never use the way to listen to the resource_id
. The same concept can be applied to index 6 to index 9. We can leave these combinations here (although users never use them) or perhaps we can forbid these combinations to make the table simpler. WDYT?
index | source resource_id |
sink resource_id |
Publish | Notification | Request | Response | Use Case |
---|---|---|---|---|---|---|---|
1 | [8000-FFFE] | None | V | A uE listens for a specific published message | |||
2 | [8000-FFFE] | 0 | V | A uE listens for a specific notification message | |||
3 | 0 | [1-7FFF] | V | A uE listens for a specific request | |||
4 | [1-7FFF] | 0 | V | A uE listens for a specific response | |||
5 | FFFF | 0 | V | V | A uE listens for all notifications and responses | ||
6 | FFFF | [1-7FFF] | V | Same as {0, [1-7FFF]} | |||
7 | 0 | FFFF | V | Same as {0, [1-7FFF]} | |||
8 | [1-7FFF] | FFFF | V | Same as {[1-7FFF], 0} | |||
9 | [8000-FFFE] | FFFF | V | Same as {[8000-FFFE], 0} | |||
10 | FFFF | FFFF | V | V | V | uStreamer listens for all notifications, requests, and responses |
IMHO the table is just getting too complicated. We should only list the known examples that uEs (and/or the streamer) should use and then get rid of any of the combinations that don't make any sense.
Then the table can be simplified as
index | source resource_id |
sink resource_id |
Publish | Notification | Request | Response | Use Case |
---|---|---|---|---|---|---|---|
1 | [8000-FFFE] | None | V | A uE listens for a specific published message | |||
2 | [8000-FFFE] | 0 | V | A uE listens for a specific notification message | |||
3 | 0 | [1-7FFF] | V | A uE listens for a specific request | |||
4 | [1-7FFF] | 0 | V | A uE listens for a specific response | |||
5 | FFFF | 0 | V | V | A uE listens for all notifications and responses | ||
6 | FFFF | FFFF | V | V | V | uStreamer listens for all notifications, requests, and responses |
These combinations only make sense to users, and we can forbid users from using other combinations explicitly. If you agree with this, then I'll update the table.
Then the table can be simplified as
index source
resource_id
sinkresource_id
Publish Notification Request Response Use Case 1 [8000-FFFE] None V A uE listens for a specific published message 2 [8000-FFFE] 0 V A uE listens for a specific notification message 3 0 [1-7FFF] V A uE listens for a specific request 4 [1-7FFF] 0 V A uE listens for a specific response 5 FFFF 0 V V A uE listens for all notifications and responses 6 FFFF FFFF V V V uStreamer listens for all notifications, requests, and responses These combinations only make sense to users, and we can forbid users from using other combinations explicitly. If you agree with this, then I'll update the table.
@evshary I'm ok with the latest changes. Please update the PR and I will approve it
As @PLeVasseur suggested here, add the table mapping for listeners and message type. This should be helpful for the implementation.