Feature Request: Export WebDAV API via Powerbox
https://github.com/sandstorm-io/sandstorm/pull/2838 adds support for apps to export and request HTTP APIs via the Powerbox.
Davros should advertise itself as implementing WebDAV!
However, we need a couple things first:
src/sandstorm/bridge-proxy.c++in the Sandstorm repo needs to be updated to cover WebDAV methods in addition to regular HTTP methods. This should be straightforward.- We need to decide what the "canonical URL" is to identify a WebDAV API. This could be some arbitrary thing like
https://fake-hostname.api/webdav. (The spec for specifying what APIs you support currently involves specifying a "canonical URL", which for a well-known services API (e.g. the Github API) would be the actual API URL to that service.)
At that point it should be a simple change to sandstorm-pkgdef.capnp to declare that Davros supports WebDAV -- and even define both "read-only" and "read-write" access -- so that other apps can connect to it.
(For now, only "singleton" APIs are supported, so the user won't be able to select a specific subdirectory or file. We'll improve that in the future...)
I'm a bit behind with my non-work projects at the moment but just want to say that this is super exciting and I'm really looking forward to implementing this. I also have a bunch of other app ideas that would tie in nicely with this.
One possibility is urn:ietf:params:xml:ns:DAV (it's not in the ns registry though) — or urn:ietf:rfc:4918 (but RFC numbers may get obsoleted by new RFCs)
https://docs.sandstorm.io/en/latest/developing/powerbox/ is now live, documenting how all this stuff works.
Setting canonicalUrl to urn:ietf:params:xml:ns:DAV to specify DAV seems like a plausible solution. At least, I think it makes a lot of sense not to use an HTTP/HTTPS URL in the case where there is no canonical URL, and we're really only identifying a protocol.
I can also see an argument for introducing a new, separate field from canonicalUrl, maybe called standardProtocol or something like that, which somehow identifies a protocol. It could be an enum (requiring updates to list every known protocol) or it could be a string (what format?).
Note that part of the idea behind canonicalUrl is that it identifies a protocol in terms of a well-known API, e.g. a Google product API, or the Github API. Eventually, Sandstorm's Powerbox will offer to connect to that actual well-known service as one option, but will also offer grains that claim to implement the same API, and perhaps also let the user specify an arbitrary URL to a third-party service. In the case of something like WebDAV, there is no well-known service to offer, so that option doesn't make sense.
For reference (to understand what I'm talking about at all), see: https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/api-session.capnp#L62
BTW, on another note: Currently raw-Cap'n-Proto apps (as opposed to http-bridge apps) can implement an arbitrary powerbox picker UI that gets embedded into the powerbox when the user chooses that grain. Currently there's no way to do this for http-bridge apps; they can only define a static list of APIs and sandstorm-http-bridge renders a picker itself.
But for Davros it would clearly make sense to let the user choose a specific subdirectory or even a specific file in response to a request.
So I would like to extend sandstorm-http-bridge to have some support for the app to show a custom picker UI, but I haven't thought much yet about the details of how this would work.