[Proposal] Alternate configuration schema

tonyg commented

2022-03-18 10:51:42 +00:00

Contributor

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...

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...

ehmry commented

2022-03-18 15:26:38 +00:00

Owner

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.

ehmry referenced this issue from a commit

2022-03-19 00:15:24 +00:00

Fix incoming Ref rewriting

ehmry commented

2022-03-19 00:36:02 +00:00

Owner

? <service-object ?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.

> ? <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.

👍 1

ehmry referenced this issue from a commit

2022-03-19 00:36:31 +00:00

New protocol and configuration from Tony

ehmry closed this issue

2022-03-19 00:36:31 +00:00

ehmry commented

2022-03-19 00:44:00 +00:00

Owner

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.

> 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.

👍 1

[Proposal] Alternate configuration schema #3