The idea is that you'd assert each ActionHandler separately to uri_runner, which would internally bring them all together; and you'd assert dataspaces to listen for XdgOpen messages separately, so that (1) uri_runner doesn't have to have a sturdyref to the dataspace inside it, it can have all its extrinsic authority passed in, and (2) you can listen on multiple dataspaces for requests.
but I'm not sure if this particular little template language pays for itself properly...
I'd like to suggest the following configuration schema for `uri_runner`:
```
version 1 .
XdgOpen = <xdg-open @uris [string ...]> .
UriRunnerConfig = ListenOn / ActionHandler .
ListenOn = <listen-on @dataspace #!any> .
ActionHandler = <action-handler @pat string @cmd [string ...]> .
```
The idea is that you'd assert each `ActionHandler` separately to `uri_runner`, which would internally bring them all together; and you'd assert dataspaces to listen for `XdgOpen` messages separately, so that (1) `uri_runner` doesn't have to have a sturdyref to the dataspace inside it, it can have all its extrinsic authority passed in, and (2) you can listen on multiple dataspaces for requests.
Then, you could have a `uri_runner.pr` like this:
```
; Expose a dataspace over a unix socket
let ?root_ds = dataspace
<require-service <relay-listener <unix "/run/user/1000/dataspace"> $gatekeeper>>
<bind "syndicate" #x"" $root_ds>
<require-service <daemon uri_runner>>
<daemon uri_runner {
argv: ["./uri_runner"]
protocol: text/syndicate
}>
? <service-object <daemon uri_runner> ?cap> [
$cap [
<listen-on $root_ds>
<action-handler "gemini://.*|file:///.*.gmi" ["/run/current-system/sw/bin/kristall" "\\1"]>
<action-handler "http://.*|https://.*|.*html", ["/run/current-system/sw/bin/firefox" "\\1"]>
<action-handler "tox:.*|uri:tox:.*", ["/run/current-system/sw/bin/qtox" "\\1"]>
<action-handler ".*\\.avi|.*\\.mp4|.*mkv", ["/run/current-system/sw/bin/mpv" "\\1"]>
]
]
```
or even
```
? <service-object <daemon uri_runner> ?cap> [
$cap <listen-on $root_ds>
$config ? <action-handler ?pat ?cmd> [
$cap <action-handler $pat $cmd>
]
]
<action-handler "gemini://.*|file:///.*.gmi" ["/run/current-system/sw/bin/kristall" "\\1"]>
<action-handler "http://.*|https://.*|.*html", ["/run/current-system/sw/bin/firefox" "\\1"]>
<action-handler "tox:.*|uri:tox:.*", ["/run/current-system/sw/bin/qtox" "\\1"]>
<action-handler ".*\\.avi|.*\\.mp4|.*mkv", ["/run/current-system/sw/bin/mpv" "\\1"]>
```
in order to allow dynamic adding/removal of handlers from the surrounding dataspace.
Another small change that might be worthwhile is to use something like
```
ActionHandler = <action-handler @pat string @cmd [TemplatePiece ...]> .
TemplatePiece = @constant string / @filename =filename / @submatch int .
```
allowing e.g.
```
<action-handler "tox:.*|uri:tox:.*", ["/run/current-system/sw/bin/qtox" filename]>
```
but I'm not sure if this particular little template language pays for itself properly...
The idea is that you'd assert each ActionHandler separately to uri_runner
This answers a question that I hadn't thought to ask yet, in some other experiments I have asserted lists of items when I should assert each item seperately. I suppose that a rule of thumb would be not to assert lists unless the list items form some context with each other.
Originally I had a dictionary of pattern keys to action values, but that would be inconsistent because there is nothing to stop multiple instances of the uri_runner to match multipe actions to a single pattern.
> The idea is that you'd assert each ActionHandler separately to uri_runner
This answers a question that I hadn't thought to ask yet, in some other experiments I have asserted lists of items when I should assert each item seperately. I suppose that a rule of thumb would be not to assert lists unless the list items form some context with each other.
Originally I had a dictionary of pattern keys to action values, but that would be inconsistent because there is nothing to stop multiple instances of the uri_runner to match multipe actions to a single pattern.
I was assuming there was an implicitly exposed dataspace over stdio, but with this is what I missing. Now I understand relays better.
> ? <service-object <daemon uri_runner> ?cap> [
> $cap [
> <listen-on $root_ds>
> ]
> ]
I was assuming there was an implicitly exposed dataspace over stdio, but with this is what I missing. Now I understand relays better.
This would work but I think the Nim type system would make it complicated to handle. The submatch index is a good idea, I may do that for #4.
> TemplatePiece = @constant string / @filename =filename / @submatch int .
This would work but I think the Nim type system would make it complicated to handle. The submatch index is a good idea, I may do that for #4.
I'd like to suggest the following configuration schema for
uri_runner:The idea is that you'd assert each
ActionHandlerseparately touri_runner, which would internally bring them all together; and you'd assert dataspaces to listen forXdgOpenmessages separately, so that (1)uri_runnerdoesn't have to have a sturdyref to the dataspace inside it, it can have all its extrinsic authority passed in, and (2) you can listen on multiple dataspaces for requests.Then, you could have a
uri_runner.prlike this:or even
in order to allow dynamic adding/removal of handlers from the surrounding dataspace.
Another small change that might be worthwhile is to use something like
allowing e.g.
but I'm not sure if this particular little template language pays for itself properly...
This answers a question that I hadn't thought to ask yet, in some other experiments I have asserted lists of items when I should assert each item seperately. I suppose that a rule of thumb would be not to assert lists unless the list items form some context with each other.
Originally I had a dictionary of pattern keys to action values, but that would be inconsistent because there is nothing to stop multiple instances of the uri_runner to match multipe actions to a single pattern.
I was assuming there was an implicitly exposed dataspace over stdio, but with this is what I missing. Now I understand relays better.
This would work but I think the Nim type system would make it complicated to handle. The submatch index is a good idea, I may do that for #4.