I created a table here before to list all the combinations of resource ID for register_listener.
The reason I removed source resource_id=FFFF & sink resource_id=[1-7FFF] is that the source resource_id should always be 0 here. However, I agree that in the L2 API case, it might be annoying for users to use //*/FFFF/FF/0 as the source Uri.
Furthermore, if we decided to add back the combination of {FFFF, 1-7FFF}, then it will come across the question I met before. Should we also add back the other cases?
When I'm using the L2 API, I found that
InMemoryRpcServer
callregister_listener
with source UUriUUri::any()
, which means//*/FFFF/FF/FFFF
. https://github.com/eclipse-uprotocol/up-rust/blob/8a9fe59882c9ad67a63c7a3a052d37a5017082e2/src/communication/in_memory_rpc_server.rs#L232I created a table here before to list all the combinations of resource ID for
register_listener
. The reason I removedsource resource_id=FFFF & sink resource_id=[1-7FFF]
is that the source resource_id should always be 0 here. However, I agree that in the L2 API case, it might be annoying for users to use//*/FFFF/FF/0
as the source Uri.Furthermore, if we decided to add back the combination of
{FFFF, 1-7FFF}
, then it will come across the question I met before. Should we also add back the other cases?@sophokles73 WDYT?