Are you a #Solid developer and do you want to share lists of movies with your friends? Check out Media Kraken Viewer: https://noeldemartin.github.io/media-kraken/viewer
Here's an example with a list of my favorite movies: https://noeldemartin.github.io/media-kraken/viewer?c=https%3A%2F%2Fdata.noeldemartin.com%2Ffavorite-movies%2F
@noeldemartin suppose Media Kraken accepted a URL param pointing to a static site that by necessity doesn't provide server-side support for SOLID but nonetheless contains publicly available, structured data.
I've got a sketch for how to achieve this; it also ameliorates frustration over how WHATWG is handling <https://github.com/whatwg/fetch/issues/878>. I'm pretty sure that a big source of friction for both SOLID and remoteStorage adoption is how unaccommodating the specs are to people with static sites.
@noeldemartin see this dev's remarks, for example, about trying to implement Webfinger (which remoteStorage uses) for their personal site: <https://github.com/konklone/jekyll-webfinger/tree/9bcb46bbabc08363b14fd8b41a944215539d7642> (Ctrl or Cmd+F for "static files".)
@colby I don't know much about remoteStorage or Webfinger, but as I understand it using a url to a "static" turtle document should work with Media Kraken. From the application's point of view, it cannot tell if it's static or not. As long as a GET request to the provided url returns a turtle document, it should work.
There may be an issue now because I'm assuming that the url to container documents end with a /, but I think you should be able to work around that with static assets.
@noeldemartin I didn't realize Media Kraken wasn't relying on the "advanced" parts of Solid's protocols, although even with workarounds, wasn't able to manage to get it to work in the brief (? kind of but not really) time I spent trying it. Those workarounds also seem to require clients ignore server-sent content type.
@colby Well it relies on authentication for the most part, but the Viewer only reads documents. My point in my previous comment is that the application doesn't really know if the url belongs to a static file or not, "static" is only a concept relevant to the server processing the request, but applications making requests don't know if the responses come from a static asset or have been generated by a backend script.
@noeldemartin, acknowledged. Problems arise if you don't have this use case in mind, though. It's easy to slip into a POLP-violating mindset and start relying on behavior that can't realistically be handled by static sites (e.g. WebFinger comments I linked). A SOLID-related example would be difficulty creating the content consumed by Media Kraken viewer if you assume the server is a full-fledged pod, because you don't have writeability—not an issue if you aim to accommodate from the start.
@colby What do you mean with POLP? I don't know what that means.
But yeah, I am assuming that the url belongs to a full-fledged Solid POD (or said differently, that it implements the Solid protocol following the spec). Although I'm not sure why that's a problem or the use-case you're trying to solve.
If you want maybe you can share a link of something you think should work with the Viewer that isn't working and I can take a look :). You can send me a DM if you don't want it to be public.
