Node-solid-server: v5 might break compatibility with other LDP servers

[RubenVerborgh]

In https://github.com/solid/node-solid-server/issues/951#issuecomment-441220974, @melvincarvalho raised the concern (in the context of v5) that:

The main issues, as I see it, with using solid as a web server on top of a file system are :

• […]
• It breaks compatibility with LDP servers
• […]

This issue servers to track any concrete breakage that would occur / occurs. Since we have no steps to reproduce so far, the "cannot-reproduce" label is applied, but it should be removed as soon as such steps are reported.

In order to be able to fix this potential bug, we need concrete example of such interoperability problems (where "concrete" means "specific enough to reproduce").

We might want to leave this open for a while to give people the opportunity to identify such bugs. If after a certain period of time no reports come in, we can reasonably assume that people are not experiencing such issues.

[melvincarvalho]

I am unsure it's a bug. Just different ways of doing things.

Within the context of pointing a web server at a folder in a file system.

Typically with an LDP server you will point it at a file system and get a number of features. You could swap out one LDP server for another and you could reasonably expect the same functionality. That might happen, it might not. But if it does, it would be a desirable property.

With the changes from node solid server 4 to 5. It is unlikely that you'll get the same functionality in the example of the WebID (path /profile/card) because card has been renamed to card.$ttl.

This need not be seen as a bug, just an incompatibility between different software. One system might take an opinionated view on some ways of doing things. What I would say is that the disadvantage is that it's unlikely that other LDP servers (to the extent that a solid server is consdiered an ldp server) are unlikely to do do the $.ttl translation so it becomes harder to swap in and out different server software.

Does it make sense?

[RubenVerborgh]

Typically with an LDP server you will point it at a file system

This is, however, not mentioned or supported in the LDP spec itself: https://www.w3.org/TR/ldp/
Typical LDP backends also include quadstores, which do not have a regular file system.

You could swap out one LDP server for another and you could reasonably expect the same functionality.

The LDP spec does not convey any expectation of what a mapping to the file system looks like, and in particular not how the content type of a (non-RDF or other) file is preserved on disk.

So an argument could be made in both directions:

• v4 is broken (wrt a presumed "LDP on disk" standard), because it assumes that extensionless files are Turtle
• v5 is broken (wrt a presumed "LDP on disk" standard), because it does _not_ assume that extensionless files are Turtle

---

Hence, can we conclude that v5 does not break LDP server compatibility, given that disk is not covered by the spec?
If so, it might be advisable to close this issue with a resolution of "no, LDP compatibility is not broken".

If the issue is that the node-solid-server v4 filesystem is incompatible with the node-solid-server v5 system, please open another issue since this is unrelated to the LDP matter we are resolving here.

[melvincarvalho]

Typical LDP backends also include quadstores, which do not have a regular file system.

My comment was in the context of servers that are pointed at a file system. Servers, that point at a quad store are something else, and off topic, wrt to this issue.

So an argument could be made in both directions:

Yes, you could argue that

However in the case of profile/card it happens (maybe by luck!) to actually serve the WebID in the right way (as turtle). And serving a WebID I would say is quite core to the server, rather than, an edge case. That could be a subjective view point.

I think fundamental to LDP is that it was designed, IMHO to be a webization of the the file system. The WG made some decisions that were not liked by all, but generally I think came to an outcome everyone could live with. What's important in a spec it so try and take a view of what it's trying to do.

If so, it might be advisable to close this issue with a resolution of "no, LDP compatibility is not broken".

You opened the issue, you are free to close it. As I stated Im unsure it's a bug. I did want to make a note of it tho.

If the issue is that the node-solid-server v4 filesystem is incompatible with the node-solid-server v5 system, please open another issue since this is unrelated to the LDP matter we are resolving here.

As stated I was simply making a note, rather than, raising an issue. As someone that runs v3 and v4, I would feel more comfortable swapping between those two, than v4 and v5. I think any documentation or guidance written down, has an opportunity to help pod owners that stumble upon information that could be useful.

[RubenVerborgh]

However in the case of card/profile it happens (maybe by luck!) to actually serve the WebID in the right way (as turtle).

No luck on the part of the HTTP system of node-solid-server (in both v4 and v5), but deliberate implementation.
On the file system, if a file named card is automatically determined to be Turtle—that is probably luck indeed. For a file named card$.ttl, no luck involved.

And serving a WebID I would say is quite core to the server, rather than, an edge case.

Most definitely. And that hasn't changed, so good.

I think fundamental to LDP is that it was designed, IMHO to be a webization of the the file system.

No such evidence in the LDP spec however (and there's the relevance of the quadstore argument).

If so, it might be advisable to close this issue with a resolution of "no, LDP compatibility is not broken".

You opened the issue, you are free to close it.

Well, you raised it—I opened this to see if there was any real incompatibility. Since there's none, let's close indeed. (And perhaps use this method to resolve all of the other points raised, this is clearly the fast track.)

[melvincarvalho]

No such evidence in the LDP spec however (and there's the relevance of the quadstore argument).

Tim has mentioned this more than once. I suggest you follow up with him, if you want to explore the topic further.

Well, you raised it—I opened this to see if there was any real incompatibility. Since there's none, let's close indeed.

I didnt raise an issue. I put down some notes in the release notes. I would want to have seen these things if I was away from the project and came back to read about v5.

That's not the conclusion of this thread. The conclusion of this thread is that quad store are off topic, given the context. You argued that both v4 and v5 could be considered incompatible, through a certain lens. Sure that would be a subjective evaluation. But my view unchanged is that v5 is within the context breaking compatibility with the type of web server you point at a file server. I hope at this point that is a bit more clear.

What I'd like to see in v 5.x is to brain storm different strategies to do this, and then apply switches to the ResourceMapper so that pod owners can improve compatibility between different systems. The one that's high on my list being NextCloud.

[RubenVerborgh]

v5 is _within the context_ breaking compatibility with the type of web server you point at a file server

So is v4, for the exact same files, so no worries there.

[melvincarvalho]

So is v4, for the exact same files, so no worries there.

That's the point I am disagreeing on.

With v4 the file /profile/card will give a webid in turtle.

Having upgraded to v5. profile/card will give a webid in turltle, but only for v5. Swapping in another server will give a 404.

[RubenVerborgh]

With v4 the file /profile/card will give a webid in turtle.

…we are talking about the file system, which will _not_ recognize the corresponding ./data/profile/card file as Turtle…

Having upgraded to v5. profile/card will give a webid in turltle, but only for v5.

…but will work on the filesystem, which _will_ recognize the corresponding ./data/profile/card$.ttl file as Turtle…

Swapping in another server will give a 404.

Of course that's the whole point of the upgrade. That has nothing to do with LDP.

So let's let the LDP matter rest. Nothing in LDP has the interpretation that a file xyz on disk should be served as /abc with content type def for any xyz, abc, def.

If we need to be compatible with such a filesystem, please open an issue for that and try to get sufficient support.

[melvincarvalho]

we are talking about the file system

Partly, we are talking about a solid server that is pointing at a file system. And what it will return. Ill point out that returning the wrong mime type is not fatal to tolerant software. But in the case of v4 the right content type as it is the default.

In the case of v5 it will work because of the bespoke extension.

With v4 you can swap in another web server or solid server and still get the webid. With v5 you cant. Im unsure how many times I can say the same thing.

So let's let the LDP matter rest

I've been trying to! I've simply taken time out of my evening to try and educate. But it seems like going round in circles. Why not take some time and try and digest the points made.

The problem here is that the whole context was around a file system. Stated and restated. The argument against was around a quad store which is off topic, out of scope and a straw man. This may reflect our different paths in coming to solid. I'd suggest taking some time out and playing with solid file systems a bit more then talking about this in the context of designing v5 -> v6.

[RubenVerborgh]

Ill point out that returning the wrong mime type is not fatal to tolerant software.

Nothing is fatal to software, but https://bugs.chromium.org/p/chromium/issues/detail?id=53782

But in the case of v4 the right content type as it is the default.

Right for card, wrong for .git/config.

In the case of v5 it will work because of the bespoke extension.

👍