Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some remaining differences between NSS and solid-rest #39

Open
bourgeoa opened this issue Aug 7, 2020 · 3 comments
Open

Some remaining differences between NSS and solid-rest #39

bourgeoa opened this issue Aug 7, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@bourgeoa
Copy link
Member

bourgeoa commented Aug 7, 2020

@jeff-zucker
Apart from resourceMapper, here are the points I can raise for compatibility between NSS and solid-rest :
(I have no understanding of Link HEADER or OPTIONS)

  • slug
    • without extension add ext to slug : slug = slug + ext (Tim's recommendation for all resources, can be forced for POST)
    • 400 slug MUST not contain / or | ( slug.match(//|||:/) ) (I seem to remember that it is for mashlib)
  • .acl or .meta ext MUST have text/turtle contentType : 415 required (spec says RDF but it has been agreed text/turtle for NSS)
  • when creating Container create default META (everything works without it)
  • container content displayed as turtle doc contains .meta
  • content Type default to application/octet-stream and not text/turtle (since NSS v5.xx and default mime-type)
  • forbidden to delete root acl, root meta (NSS POD broken)
  • /profile/card contentType is text/turtle and file is card$.ttl ( the last point I suppose can be left to resourceMapper)
  • Resource name must be unique (Container without / at end and Resource) (not in NSS actually)
@bourgeoa bourgeoa changed the title Some reamaining differences between NSS and solid-rest Some remaining differences between NSS and solid-rest Aug 7, 2020
@jeff-zucker
Copy link
Member

Thanks much, this is a great list.

  • slug without extension add ext to slug : slug = slug + ext

This is for POST only, and Resource only, correct? I can still PUT a resource without extension or POST a container without one?

  • 400 slug MUST not contain / or | ( slug.match(//|||:/) )

We already disallow / and test for the 400 in the tests. I'll add |.

  • .acl or .meta ext MUST have text/turtle contentType : 415 required

Presumably all aux files? And we should require the user to supply this rather than supply it ourselves automatically?

  • when creating Container create default META

A zero-byte file, correct? And we need to 1) create Container 2) read created Container's link header 3) use that address to create the .meta.

  • container content displayed as turtle doc contains .meta

I presume this is in the new aux spec? I've never seen it explicitly stated anywhere. Nice feature though.

  • content Type default to application/octet-stream and not text/turtle (since NSS v5.xx and default mime-type)

When would this apply? My understanding is that both PUT and POST require a contentType, so they should error if there is none specified. And the extension is irrelevant to this question, right? Once the resource-mapper is implemented, the specified contentType will be used regardless if it matches the extension?

Also, this is an NSS thing, not in the spec?

  • forbidden to delete root acl, root meta (NSS POD broken)

Yes, we should disallow that..

  • Resource name must be unique (Container without / at end and Resource)

I guess this means that the solid-rest equivalent of itemExists() should always check both with and without a trailing slash?

@bourgeoa
Copy link
Member Author

bourgeoa commented Aug 7, 2020

  • slug without extension add ext to slug : slug = slug + ext

This is for POST only, and Resource only, correct? I can still PUT a resource without extension or POST a container without one?

yes

  • 400 slug MUST not contain / or | ( slug.match(//|||:/) )

We already disallow / and test for the 400 in the tests. I'll add |.

yes. (even if I don't understand the rationale)

  • .acl or .meta ext MUST have text/turtle contentType : 415 required

Presumably all aux files? And we should require the user to supply this rather than supply it ourselves automatically?

Presumably yes. In fact there as been a discussion, the result being it MUST be RDF and that for parsing reason in NSS it can only be text/turtle. The check is needed, and yes the contenType is provided by the user

  • when creating Container create default META

A zero-byte file, correct? And we need to 1) create Container 2) read created Container's link header 3) use that address to create the .meta.

yes. zero-byte file. In solid-rest I was with the impression that you choose a simplification and that you don't need to read Container's link header. NSS do not read it allready knows where to store it.
This is the choice I also made for _getLinks() in solid-rest.
If you think an other route is needed, I suppose you will have the header to depend for some properties on storage()

  • container content displayed as turtle doc contains .meta

I presume this is in the new aux spec? I've never seen it explicitly stated anywhere. Nice feature though.

I shall check the spec. I remember seeing it in the spec discussions

  • content Type default to application/octet-stream and not text/turtle (since NSS v5.xx and default mime-type)

When would this apply? My understanding is that both PUT and POST require a contentType, so they should error if there is none specified. And the extension is irrelevant to this question, right? Once the resource-mapper is implemented, the specified contentType will be used regardless if it matches the extension?

Also, this is an NSS thing, not in the spec?

I shall recheck to see if I can find more details.
What I am sure about is that :
-- a file without extension should default to application/octet-stream
-- an unknown contentType provided by the user defaults also to application/octet-stream
It is not in the solid spec but I think it is in other general spec

  • forbidden to delete root acl, root meta (NSS POD broken)

Yes, we should disallow that..

Not sure it is allready in the NSS code but I think is has been added in mashlib

  • Resource name must be unique (Container without / at end and Resource)

I guess this means that the solid-rest equivalent of itemExists() should always check both with and without a trailing slash?

Not implemented in NSS but a recurrent low level demand from Tim.

As you can see I was not precise enough.
There is some uncertainty in some cases where the distinction : is it a NSS issue or mashlib one is not understand by me.

@jeff-zucker
Copy link
Member

Thanks, your explanation is very helpful.

@jeff-zucker jeff-zucker added the enhancement New feature or request label Aug 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants