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

implement a resource mapper like solid NSS #32

Open
bourgeoa opened this issue Jul 31, 2020 · 6 comments
Open

implement a resource mapper like solid NSS #32

bourgeoa opened this issue Jul 31, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@bourgeoa
Copy link
Member

This is a way to store in file and retrieve from file the Resource and contentType :

  • card -> card$.ttl
  • file.ttl text/turtle -> file.ttl
  • file.text text/turtle -> file.txt$.ttl

We could also implement a server slug creation with POST when resource exists.

@jeff-zucker
Copy link
Member

Why? What does this change about what solid-rest can do?

We could also implement a server slug creation with POST when resource exists.

Again, why?

@jeff-zucker
Copy link
Member

Ah, maybe by "server slug creation with POST" you mean the ability to create filenames (prepend a number) when a resource already exists? If so, yes I think we need that.

@bourgeoa
Copy link
Member Author

That's exactly what I meant.for POST.

@bourgeoa
Copy link
Member Author

As for using a resource mapper function.
The use case can be

  • use a POD copy and update back
  • make a backup, restore a backup

These case needs to be able not to break the file contentType relation, even when not reflected by the extension.
The convention can be different from NSS ,but I think there should be one.

@bourgeoa
Copy link
Member Author

I already run on some setup test questions on solid-file-client when the relation between resource and contentType is not reflected on ls:// or file:///

@jeff-zucker
Copy link
Member

Moving the POST questions to its own issue;

Marking the resource-mapper as enhancement. I think it is definitely needed but not as high a priority as other things given that it only applies to a very specific circumstance that isn't really specified (AFAIK) in the spec.

@jeff-zucker jeff-zucker added the enhancement New feature or request label Jul 31, 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