Add the table for listeners to distinguish different message types.

[evshary]

As @PLeVasseur suggested here, add the table mapping for listeners and message type.
This should be helpful for the implementation.

[PLeVasseur]

Hey @evshary -- is this generally useful to include in e.g. the uAttributes spec?

That's what I had originally thought

[gregmedd]

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.

[evshary]

@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]

Please see comment

[stevenhartley]

Made some comments but what I would also like to see @evshary is another column of the first table that explains the use case for said combination, by that I mean:

src resource_id	sink resource_id	Publish	Notification	Request	Response	Use Case
[8000-FFFE]	None	V				A uE listens for a specific published message
[8000-FFFE]	0		V			A uE listens for a response to a specific notification
[1-7FFF]	0				V	A uE listens for a response for a specific request
FFFF	0		V		V	A uE listens for all notifications or responses
FFFF	[1-7FFF]			V		A service listens for requests coming in from anyone to a specific request
[1-7FFF]	FFFF				V
[8000-FFFE]	FFFF		V			Streamer listens for any notification from anyone
FFFF	FFFF		V	V	V	Streamer listens for anything that is sent to this device

[stevenhartley]

I don't think this is a valid usecase for source and sink matching

[evshary]

I left the comments below. Please let me know your thoughts.

[stevenhartley]

Another usecase that I think is not valid

[evshary]

I left the comments below. Please let me know your thoughts.

[evshary]

@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

[stevenhartley]

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.

[evshary]

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.

[stevenhartley]

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.

@evshary I'm ok with the latest changes. Please update the PR and I will approve it

[stevenhartley]

Sorry @evshary but I'm reminded of what I actually implemented in up-java. The InMemoryRpcClient.java will register a listener for source=FFFF, sink=0 so that it can get all responses. Additionally, InMemoryRpcServer.java will register a listener with source=FFFF and sink=[1-7FFFF] to be able to receive requests from any client for a specific method so we need to add those options to the table...

[evshary]

For the case source=FFFF, sink=0, it's covered at index 5.
However, I'm not sure about source=FFFF, sink=[1-7FFF]. Could we use source=0, sink=[1-7FFF] to cover it?
I mean we can set Authority to any, but specify the resource_id must be 0. It doesn't make sense for any other resource_id.

UUri {
  authority_name: "*",         // any authority
  ue_id: 0x0000_FFFF           // any instance, any service
  ue_version_major: 0xFF,  // any
  resource_id: 0
}

I'm fine to add it back, but in that case, should we also add the index 7-9 back? I removed them because they can be covered by other cases.

[stevenhartley]

I'm not sure this is valid because it will them mean the streamer will register for listeners for itself. @PLeVasseur what are you passing to the transports now in up-streamer-rust?

[PLeVasseur]

Should be okay.

This is for the resource IDs only, which is a much more narrow scope. The uStreamer still has the ability to discriminate based on the authority_name.

Here's a snippet of code showing how we currently use FFFF, FFFF for source and sink resource IDs. You'd have to read up a bit to see the definitions of the functions for creating the UUris here.