Node-solid-server: Alternative upgrade paths for 5.0.0

[melvincarvalho]

This thread is a discussion regarding upgrading pods for the extremely paranoid.

The standard upgrade path requires renaming users files (for example profile/card -> profile/card.$ttl) for example.

The assumption is that most users wont notice this, which seems to be sound. Pod owners probably may notice it, and will need to run a script, but otherwise, I think there is a reasonable upgrade path.

However, for the paranoid like me, renaming a users file is something I'd rather not do if it can be avoided. The idea being the user owns their own data, and that includes files -- so I'd like to keep my hands off that (even if it's undetectable), if I can help it.

I fully appreciate not everyone will want such an alternate upgrade path. And I feel the current path is reasonable. So I have marked this as low priority, and as discussion, appropriately.

This thread is to think about is there a way to upgrade to 5.0 without changing files. I think there may be a way as follows :

• Take the server down
• Upgrade to node solid 5.0 and install
• Set the default content type to text/turtle (from octet stream) in the ResourceMapper
• Restart the server

This will largely keep the server running as per 4.4 but with the bug fixes of 5.0, all except one. And that is the (important) edge case where a file without an extension will default to turtle (as it does today).

There is a difference however. Given the way that we will now use the ResourceMapper, it might be able to create a quick patch (something built over a weekend) that will find another mechanism to preserve content type. If done well, that patch could be contributed upstream.

This is just food for thought at the moment. Polite feedback welcome!

[kjetilk]

Mmmmm, patches welcome, as they say. It seems to me that to use the LegacyResourceMapper would retain the old way.

Do note, however, that there are serious flaws in the ACL implementation with regards to origin. It is like the front door is open, so my paranoia would have been placed there. :-)

[RubenVerborgh]

I like the idea to check whether there is community support for alternative paths. If there is, let's consider; if there's not, let's not.

Although I wonder whether this should be on the spec level (too); I think we need to keep the wishlist for HTTP/filesystem correspondence and the actual implementation separate, in order not to introduce technical mistakes or confusion, like this issue already does.

• Set the default content type to text/turtle (from octet stream) in the ResourceMapper

That will completely mess up your pod the moment you do a PUT or PATCH request on existing resources such as /card, resulting in both /card and /card$.ttl on disk, a 50/50 chance of either being returned on subsequent GETs, and god-knows-what on folder listings and globbing.

That's why we should keep the wishlist and the implementation details separate.

As I have told you when you first asked me (https://github.com/solid/node-solid-server/issues/950#issuecomment-440562194), and as Kjetil confirms above, LegacyResourceMapper was written and tested by me specifically for the purpose. So in lib/resource-mapper.js, replace ResourceMapper by LegacyResourceMapper. If there ever were a switch or choice, this would be how you'd do it (but let's first get community support).

[melvincarvalho]

I like the idea to check whether there is community support for alternative paths

Sure! As the owner of the domain solid.community, which has 40,000 users, and I am interested in the possibility, at this point.

Just exploring options!

[melvincarvalho]

@kjetilk thanks for the notes, very helpful!

[melvincarvalho]

That will completely mess up your pod the moment you do a PUT or PATCH request on existing resources such as /card, resulting in both /card and /card$.ttl on disk, a 50/50 chance of either being returned on subsequent GETs, and god-knows-what on folder listings and globbing.

So could this be considered a bug. Or perhaps if we allow the setting of a configurable default content type it could be a bug? I guess this is one of those bug vs feature topics.

LegacyResourceMapper was written and tested by me specifically for the purpose

Ok right, so perhaps its possible to explore what it would take to swap between the two, would it be dozens of file changes, for example?

I'd possibly prefer to make the new system more flexible than go with Legacy, but whatever is practical works.

So in lib/resource-mapper.js, replace ResourceMapper by LegacyResourceMapper. If there ever were a switch or choice, this would be how you'd do it

Sounds promising, that this could be a one line change, I'll explore the code further!

That's why we should keep the wishlist and the implementation details separate.

So I suppose we could define what's on the wishlist. Though that's going to be subjective. To me I find the idea of solid as a webization of the file system to be the vision. For others I suppose a quad store might be the vision. Hopefully, this wont turn into one of those religious wars that split communities, we could be wary about such type of issues (eg jsonld vs turtle etc.), because this is a known phenomena in the dweb (just look at crypto currencies!).

For reference I'd like to consider the widely acclaimed web server, serve :

https://github.com/zeit/serve

This is notable in that it is very easy to set up. You just run it in a file system and you are ready to go. That is the kind of ease of use I'd like to eventually see with node solid server. Agree / Disagree / Thoughts?

[RubenVerborgh]

So could this be considered a bug.

Nope, using the old filesystem layout with the new mapper is.

Ok right, so perhaps its possible to explore what it would take to swap between the two, would it be dozens of file changes, for example?

Just the upgrade script.

To me I find the idea of solid as a webization of the file system to be the vision.

And there's different mappings to do so: https://www.w3.org/DesignIssues/HTTPFilenameMapping.html
If there's traction, we can support multiple.

Hopefully, this wont turn into one of those religious wars that split communities

Let's make it not.
That's why I think it's great that the current specs, both LDP and Solid, only specify the interface but not the backend. And in absence of such a spec, there should be no assumptions about that backend.

That is the kind of ease of use I'd like to eventually see with node solid server.

+1, but in my opinion not possible without #788.

[melvincarvalho]

Let's make it not.

OK, let's upgrade solid.community to the 5.0 path then.

One issue, as I see it, is that NSS 5.0 will be the only web server on the planet with this mapping. It's hard to imagine other servers following this rewrite rule (but you never know).

It would be nice if, in future there was a path to align the mapping with the standard card -> card that we see in other servers, and that prevents having to rename users' files.