update to solid v0.10 spec

[bourgeoa]

• Headers and tests
  • add storage header for root
  • Allow header is not ACL dependent but resource dependent
    POST not allowed on document, PATCH not allowed on container, DELETE not allowed on root and root/.acl
  • Vary Header
  • Access-Control-Expose-Header
  • add new accept properties Accept-put, Accept-patch
  • update headers for new accept properties on GET
• agent authorization
  • create new resource with Append on PUT
  • owner has Control on all ACL's
• method conditions
  • review DELETE : ACL conditions
  • POST not allowed on document, PATCH not allowed on container, DELETE not allowed on root and root/.acl
• precondition if-non-match: *
• security
  • return errors on DELETE : 404 --> 403/401
  • check itemName on creating intermediary containers

solid-rest improvements :

• n3-patch tests
• contentType mapper when extension missing or incompatible --> $.ext
• add metadata to container representation
• http front server
  • express server
  • dataBrowser with an index.html at root
  • redirect to dataBrowser programmatically like in NSS
  • default card in server
  • permanent location for /profile/ and /settings/ : see installDir in data-kitchen

It will be nice to have a way to run the test-suite and specification tests

[bourgeoa]

@jeff-zucker If you want to add any things

[jeff-zucker]

@CxRes - do you have things to add,? even wishlist things?

[jeff-zucker]

@bourgeoa - While I think it would be cool to get solid-rest up to the specs and to run a server from it, I'm not sure if that would be useful to anyone. @CxRes is the only person I know who uses solid-rest so he may have a different opinion. For me, the main thing I use it for is being able to run basic rdflib operations (load and putBack and webOp) against the file system. It does support update and SPARQL patch but, I think most people who need those kinds of operations against the file system are better served by running a local server. I can be convinced otherwise, but these are some of the reasons I have not put time into solid-rest.

[CxRes]

@jeff-zucker I have been out of this for so long that I would need to think back. I was reading our extremely long convo more than three years ago about Solid-REST 2.0 architecture to try and refresh my mind. Essentially (if I recall correctly), my thoughts were that everyone using Solid should be connecting through Solid-REST rather than to Solid using HTTP, giving instant access to all kinds of storage spaces as if they are Solid. What I am unsure of is we need to design this completely from scratch any more, given the advent of things like unstorage https://unstorage.unjs.io/.

[CxRes]

Also, I was just speaking with Prof Lixia Zhang (UCLA) who wants to use Solid with Named Data Network (NDN). If you start wanting to do that, your best bet is probably Solid-REST.

[jeff-zucker]

I made it not show files starting with "." or "#" in container listings and added a very basic server. It has bugs but works with the data-kitchen SolidOS databrowser front end. Haven't tried making it serve the databrowser directly. Images are broken. Basic get and put and container listing seems to work fine.

[bourgeoa]

• Allow header is not ACL dependent but resource dependent
  POST not allowed on document, PATCH not allowed on container

@jeff-zucker this is my understanding. It is what is implemented in CSS and NSS
Do you agree ?

[jeff-zucker]

@bourgeoa - I haven't kept up with spec changes enough to know, but I trust you and see no reason to diverge from CSS/NSS.

[jeff-zucker]

@bourgeoa you may want to use #56 to track the spec related changes.

[bourgeoa]

@jeff-zucker
I'm encountering some difficulties to implement some specifications related to the fact that solid-rest has no pod root concept for file.
For the server you created the docRoot which is the Express hostname.

In the tests you introduced the host concept
I wonder if we could introduce in solid-rest request.hostname. This plus the request.url would be enough to define request.path

This would allow to define a podRoot for solid-rest/file and to manage prohibited actions related to req.pathname like

• cannot DELETE root, root/.acl, profile/card
• Storage header

In my idea I thought it could be complementary to the serverlessPod but not identical.

A pod could have been defined as a serverless pod + a storage.
This concept might not be a workable idea. I see that your serverless pod includes /public /private and /inbox.

[jeff-zucker]

I see some benefit to doing this inside solid-rest. This would take care of the case in which a person had no local profile or other infrastructure but should also work when they do have one. We should definitely add the root storage in the serverLess pod. Solid-shell has a way of setting both local and remote roots (either via command-line or via environment variable). If we're going to have usable settable roots inside solid-rest, we should follow what solid-shell does. I can look at that and add it to the server startup.

[jeff-zucker]

A pod could have been defined as a serverless pod + a storage.

Oh, I really like that idea. I had been doing it where ~HOME environ var was linked to /pubic in the serverless pod, but if instead it treated the storage statement in the profile as a pointer to the local file docRoot, that would be even cleaner. Then solid-rest itself could redirect /.acl and /profile to MyPod but all other /* to docRoot.

[jeff-zucker]

@bourgeoa - in regard to the content-type - I really dislike the idea of using $.ttl etc. because this is my file system and I don't want things mucked with that way. I wonder if we can store this information in the .meta of the container. I believe the spec allows that and that a GET on the resource should contain triples about it in that .meta.

[bourgeoa]

@jeff-zucker

• You should consider that it is only used when creating a file where the filename as no extension or when the extension is not compatible with the required content type. These are rare cases with the exception of /profile/card which is stored as /profile/card$.ttl, we can make a programmatic exception for card.

  The advantages are that

  • you will not fail when importing files from an other pod.
  • and your filesystem will not need to guess the content. this may not be a real issue due to the rare occurence

Your idea is valid

• but .meta is automatically added to container representation and you will have 2 contradictory content type and the data browser will use the wrong content type.
• Clean merging should be possible but induce some thinking and work.

If you maintain your view I would prefer that solid-rest errors on file creation with 406 for incompatible contentType and manage exceptions for text/turtle card. Auxiliary resources are already an exception.

[jeff-zucker]

I guess you are right that this is rare, I withdraw my objection, we can eventually add in NSS-style mapping.