You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
.up-rust/src/communication/in_memory_rpc_server.rs
Line 232 in 8a9fe59
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?@sophokles73 WDYT?
The text was updated successfully, but these errors were encountered: