implement a resource mapper like solid NSS

solid-contrib / solid-rest

a client-side API which supports any backend for Solid requests

37 stars 9 forks source link

implement a resource mapper like solid NSS #32

Open bourgeoa opened 4 years ago

bourgeoa commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

That's exactly what I meant.for POST.

bourgeoa commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.