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

Add migration instructions for older apps #607

Closed
RubenVerborgh opened this issue Aug 3, 2021 · 10 comments
Closed

Add migration instructions for older apps #607

RubenVerborgh opened this issue Aug 3, 2021 · 10 comments

Comments

@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Aug 3, 2021

No description provided.

@NoelDeMartin
Copy link
Contributor

NoelDeMartin commented Aug 14, 2021

I started making Solid apps exclusively on NSS and trying other servers (not just CSS) I've found a couple of things I needed to change, so maybe it's useful if I share the main ones that come to mind.

To clarify, these are things that Solid apps should NOT depend on:

@jeff-zucker
Copy link
Member

Great list @NoelDeMartin. I would change your second paragraph to "things your app should NOT depend on". We certainly can use typeIndex, mtime, etc. when they are available, there is nothing wrong with a server making them available, what's wrong is counting on them to be there. The use of solid-auth-client probably, unlike the others, should be in the do not use list.

@NoelDeMartin
Copy link
Contributor

Thanks for the suggestion @jeff-zucker, I just edited it. I'll leave solid-auth-client in the same list because I still use it in my apps, it works better with old versions of NSS than Inrupt's client. But it's not the default authentication option.

@Vinnl
Copy link
Contributor

Vinnl commented Aug 16, 2021

@NoelDeMartin pim:storage in the profile should exist, according to the spec according to @csarven:

Clients can discover a storage by making an HTTP GET request on the target URL to retrieve an RDF representation [RDF11-CONCEPTS], whose encoded RDF graph contains a relation of type http://www.w3.org/ns/pim/space#storage. The object of the relation is the storage (pim:Storage).

So it looks like we should be able to assume we can determine the storage, and that the fact that CSS doesn't is a bug in CSS. @matthieubosquet said he was going to respond to that (which is why I didn't report a bug), because he believed profiles didn't need to list storages (which is why CSS doesn't), but he hasn't responded yet at this point in time.

@Vinnl
Copy link
Contributor

Vinnl commented Aug 16, 2021

I didn't report it because Matthieu said it was intentionally left out, but reported here now: CommunitySolidServer/CommunitySolidServer#910 Listing it in the template sounds perfectly fine to me.

@csarven
Copy link
Member

csarven commented Aug 16, 2021

The Protocol does not require that a profile includes pim:storage. I don't think it is a CSS bug.

But @Vinnl I think what @NoelDeMartin is referring to this instead:

Clients can determine the storage of a resource by moving up the URI path hierarchy until the response includes a Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage. Clients may check the root path of a URI for the storage claim at any time.

and for that yes the server is required to:

Servers exposing the storage resource MUST advertise by including the HTTP Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage when responding to storage’s request URI.

I don't know if that's a CSS bug or not.


Although that's not recommended either.

Some claiming "legacy" is not the same as consensus :)

@matthieubosquet
Copy link
Member

matthieubosquet commented Aug 16, 2021

This is not a bug in CSS.

Clients can discover a storage by ...

  1. That is not a MUST
  2. If a MUST related to that existed, then all resources served by a Solid server would include an authoritative statement pointing to their storage
  3. However, there is nothing mandating that a WebID is stored in a Solid server, besides that, any number of storages might be "owned" by a WebID AND there is no requirement for a storage to advertise its owner (so, by extension, there should be no requirement for a WebID to advertise all the storages it owns)

So to your question @Vinnl:

if someone logs in to my app with their WebID, how do I figure out where to store some particular data?

I'm afraid, there is no answer.

An application can not and for that matters, will never be able to consistently determine where to store data based on the WebID used in the session.

Probably that moving up the path URI can help a little in some cases, that is if: the server decides to advertise its owner AND the WebID is stored in a Solid server AND the Solid server used to serve the WebID is where the user wants to store that "particular data".

In truth, the user will need and should have a way to determine where data is stored and that's quite complex and prone to judgement calls and errors.

As @justinwb mentioned in gitter, those questions are being addressed in the data interoperability panel. But I'm afraid, there is no consensus or standard way to answer your question. In any case, I think apps will need to keep track of storages and provide adequate help for users to chose where to store their data.

@Vinnl
Copy link
Contributor

Vinnl commented Aug 16, 2021

@matthieubosquet I took it back to Gitter since it's not really related to this issue or even this repository, so hard to track for people it might be relevant to: https://gitter.im/solid/specification?at=611a44153eec6d41d15c0c09

@jeff-zucker
Copy link
Member

An issue for implementers to keep in mind : CSS does not label the iana media type of resources in the listing of a container. On NSS we counted on being able to look for a triple with the content-type in the container's RDF. Things that count on knowing the content-type of contained resources (like the mashlib databrowser's slideshow) will not work. See SolidOS/solid-panes#301. Am I right in assuming that the specs do not require the content-type and that therefore this is an issue on solid-panes rather than on CSS?

@bourgeoa
Copy link
Member

@jeff-zucker @RubenVerborgh

Some specifications are the result of existing specifications and implementations depending on maturing ideas and server implementations.

Here the problem has I see it is that :

  • contentType is a MUST on create and it is surprising not to be able to be returned back in container. A resource is defined by a pair of content and content-type. This pair can have different representation but it does not seem the point here in displaying container content.
  • it is available in GET or HEAD and there is no other way to find it, even on NSS or CSS the resource name cannot give you the contentType

The argument of representation does seem to me something else and not related to returning the resource contentType used on creation or update

So yes there is an issue in dataBrowser and all apps using the container to find the contentType, if the contentType is not available in the container.
The solution of doing a HEAD from browser is much heavier than server side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants