What is the purpose of the "path" in register_request_handler API call?

[ThomasFreedman]

Looking at the request / response example. The value provided in the registered handler is "/random/text" but it's not used in the random_text_generator function.

What is the purpose of path? It is a required parameter to register the handler, and presumably multiple requests / msgs could be received on the link, so I can't see it used as a request or msg type to aid in dispatching incoming requests to an appropriate handler.

[ThomasFreedman]

After I re-read the "Understanding Reticulum" path is described as a dot delimited naming scheme related to the optional aspect parameter. Not sure why your example uses '/' characters and the code uses the name path and not aspect.

Am I getting these concepts mixed up?

[jonarmani]

Yes, you're confusing the request path with the destination name. The former can be arbitrary text, as far as I can tell (the example you use employs UNIX path-like structure but I don't think it's required), to uniquely name a resource over a link. The latter is dot-notated, then hashed to produce a unique address reachable across networks.

The request path would not be in the handler. You should see it further down in the example, when the client requests it:

server_link.request(
    "/random/text",
    data = None,
    response_callback = got_response,
    failed_callback = request_failed
)

The broader idea is that you can register resource handlers for several things, like additional handlers "/random/image" and "/random/sound." Clients request whichever they want.

I brainstormed an index-based setup once, if you want more dynamic resources whose name you haven't agreed upon prior with the clients. You agree on a resource named "index" whose callback on the server would spit back the active list of other resources the link provides, which the client can then request by name.

[ThomasFreedman]

Yes, thanks. It's slowly sinking in. My client app is the only place I actually provide an aspect arg, to limit the announcements its' handler sees, and as the value of "path" in the Link.request method. I also use app_name on my server app to register the link request handler.

Apparently the use of the arg name "path" in the Link.request context (and perhaps a few others as well) should be "aspects" instead. I am still a bit foggy on it, and I wonder if the value I see for path provided to the response_generator would be different if my client & server were more than 1 hop away. They are connected via mutual transport node they both connect to on the Internet.

[markqvist]

You can think of the path argument as somewhat akin to the path component of an URI.

The purpose of the path argument in the Request API is to allow you to create different request handlers, mapped to different logical namespaces.