solid/specification

Identify Solid Server and Spec Version

CxRes opened this issue · 6 comments

CxRes commented

The Solid specification would undergo many changes over the course of its lifetime. Therefore, it would be necessary for a client to know which version of the standard is implemented by the server.

In response to HTTP requests, the server must identify that it implements Solid and the version of the spec it complies to!

Currently NSS provides a x-powered-by header but it refers to a particular implementation as opposed to the standard. One would have to then get the spec details out of band.

csarven commented

Whether to have a spec version or a living standard is dependent on #8 .

Whether there is a 1:1 mapping between a spec version (if there is one) and HTTP header indicating the spec version is open for discussion.

Why would a client need to know a server's conformance to a spec version (eg. through an HTTP header)? Why not use OPTIONS to check the exact capabilities?

or maybe have the server expose its test reports eg. Trellis' implementation report of LDN available in RDF: https://linkedresearch.org/ldn/tests/reports/9cd86580-bcda-11e8-a3c6-59f9fd1c0455

See also solid/solid#77 ( https://github.com/solid/solid/blob/master/proposals/server-capability-discovery.md ) , #163

  • 👍1
dmitrizagidulin commented

I agree with @csarven, that an OPTIONS or HEAD or whatever server capabilities discovery mechanism we settle on, that lists the server's implemented features, is better than a spec version header. Although I initially liked the idea of a version header, I realize that there are a lot of optional parts of the spec. And if two servers are implementing the same spec version # (down to the major, minor and patch version levels), they still will implement a different subset of optional features. So you might as well just rely on capabilities discovery (duck typing :) ), in any case.

  • 👍1
CxRes commented

The above claims about discovery would be true if Solid were restricted to RESTful resource access. However, this does not seem to be the case afaict. Some issues I face or foresee as a client developer:

  1. In the older spec repo, @RubenVerborgh ties this issue with WebSocket capabilities in issues solid/solid-spec#220 and solid/solid-spec#221. The client needs to know which WebSocket messages are supported, what their syntax is etc. Certainly, details like syntax, grammar etc are not suitable to be be advertised in headers, they are more likely to be a part of a spec. Advertising, a spec version here would be the similar to announcing that you are using HTTP/1.1

  2. For example, consider a planned deprecation, like globbing. Now, I do not see a header that informs the client of this feature. The client will be clueless when the server will take it away. Again, the client needs to be aware of an extra feature/restriction beyond the standard, not all of which are suitable for headers.

  3. I am currently duck typing (reading the x-powered-by header) to just detect if I can process the response as if it is from a solid server or to just let the browser handle it. This is a horrible solution. Solid specifies responses, such as, for containers and life is much easier if I know that I am dealing with a Solid container upfront (as opposed to parsing the response to discover that the response is Solid container-like; I won't still know for sure that server has sent me a full listing as required by Solid or something that just happens to looks like a listing but is something else).

However one plans to resolve this, client must be provided with information to know of all the ways to proceed further (not just the HTTP affordances) by the server. This is not the case right now.

csarven commented

Adding to above:

  1. Linked to #163 earlier which already references WebSocket for consideration - so it wasn't overlooked. Note: solid/solid-spec#221 (comment)
  2. Dependent on #8 . The specs are intended to be backward compatible. Globbing was used in Unofficial Draft but there was consensus to not include it going forward: #64
  3. Client knows a resource is a container because of shared slash semantics: #35 (comment) . It can also inspect the HTTP headers ( #128 (comment) ) and data.

Expressing a server's capabilities through a unit (eg. spec version in HTTP header value) is at best implies that the server at most implements the required criteria, and worse it is lossy - can't rely on that to know whether the optiona criteria is implemented.

Client doesn't need to hop through to get a packaged understanding of what's supported. It should be able to figure out what's exactly possible (and how) and I think that's far more useful.

CxRes commented

@csarven I do not understand the intent of point 3. Slash semantics I thought would only be meaningful when as a client I already know that the response originates from a Solid server. How do I differentiate such a response from, say, one from a non-solid complaint LDP server which might also send me a rdf link header? (Its contrived but conceivable!)

More generally, I agree that a direct mechanism for the client to gain knowledge is preferable. Detailed indirect information might be a little less preferable but would better than a version number. Just as long as the client knows how to proceed...

csarven commented

The HTTP headers pertaining to LDPC for Solid-servers and LDP-servers are the same. #128 (comment) is intended to ensure that consistency.