"static site" handler

[zenhack]

I'm willing to do the legwork on this feature, but wanted to get other folks' opinions first.

Motivation: I'd like to be able to write single-page applications that don't have their own servers, and are served directly out of perkeep. For example, right now I've got a janky feed reader written in Elm, with a Go server that has two responsibilities:

1. Serve the static files that constitute the web frontend.
2. Proxy the perkeep APIs.

It needs to do (2) because of CORS, otherwise the frontend could call out to perkeep directly. It's actually possible to skip this step now, if you're willing to punch this into your URL bar:

http://<perkeep-host&port>/ui/download/<blobref>/index.html

...assuming that you've got an html file that's entirely self-contained. But this isn't particularly usable.

What I'd like to see instead: I'd like to be able to put an entry in a low-level config like this:

"/feed-app/": {
    "handler": "static-site",
    "handlerArgs": {
        "camliRoot": "myapp",
    }
}

Then, I could "install" the app by copying the files into <fuse-filesystem>/roots/my-app.

Thoughts?

[zenhack]

Another approach, which is much simpler to implement, but only covers the single file case: Just add a view fragment to the UI for html files; on top #1276 it would be a one-line patch. One addition I would probably want to add though is a filter that will only view documents of certain "dangerous" types if they're marked as "trusted", via some special attribute that could be set; otherwise I could see some nasty xss stuff happening with just adding text/html to that list.

[edrex]

i've wanted a handler for serving static SPAs for awhile, big +1 for that

the fragment thing is pretty loosy goosy as far as security and I doubt it would get merged, even with a guard attribute. I like data->code quines as much as the next mathematician pretending to be an engineer but thankfully there are others not of that ilk on this project :D

ps just noticed your recent activity, happy to see and I'll read through and respond where I have something to offer.

[edrex]

also yay Elm :D

[mnzaki]

I am working on this! I have been converging on a similar direction, but I was calling it an "app-server".

Ideally the ui handler is reduced to a simple auth mechanism and all other user interfaces run as such "apps" with a different handler on a different port (to leverage browser sandboxing) and request auth tokens from the ui handler which can give users a trusted UI to accept access from an app running from a specific blobRef.

But I would make it such that there is 1 "app-server" handler to configure, with no particular roots even. Any html file uploaded to perkeep can be an app basically. It's just that the iframe would load it from the app-server instead of from the ui handler.

This is all in a planning phase currently (because I am also grabbing a few other low hanging fruits first) but I'm improving on the approach bit by bit.

The plan is to extract the ServerConnection.js bits and reuse them in a new npm library, a perkeep.js ("perkapps" is a term I've been throwing around as well).

[edrex]

@anborg your comment is pretty off topic on the perkeep issue tracker. that said, a lot of ppl use a pull requests on a SCM host like Github or Gitlab for change management for static sites, with embedded edit links in each page. There's also https://stackedit.io/

[angelcabo]

I also thought this might be a nice addition, but I originally thought the functionality might make sense to merge with the existing publisher app (i.e. allow serving a template from a camliRoot rather than requiring the template to be served from disk as it currently works).

But instead of making that change, I took a stab at a simple static site handler as described here. The PR is at #1579. If anyone on this thread feels like testing it out, I'd appreciate any feedback.