Repository navigation
Remove the Container .meta mechanism #547
Description
From the discussion with @timbl yesterday, the decision was made that the current container .meta mechanism is not very useful, and may be counter-intuitive to developers, and so should be removed.
- Currently, a PATCH or a PUT with a body to a solid container puts the triples in the request body into that container's
.metaresource. Disable/remove that logic. - The contents of a container's
.metaresource gets appended to the container listing no a GET to that container. Disable/remove logic. - Update Solid spec to reflect this change.
Activity
dmitrizagidulin commentedon Aug 17, 2017
Discussion came about as a result of PR #513.
timbl commentedon Oct 23, 2017
One place the .meta is currently used is for people who have their profile in a URI ending in /, like http://csarven.ca/#i etc See gitter discussion https://gitter.im/solid/node-solid-server around Oct 20 12:17 ( https://gitter.im/solid/node-solid-server?at=59ea219ef7299e8f53109eb4 )
csarven commentedon Oct 23, 2017
Just to have some documentation here: I am not currently using
.meta. We were considering the possibility because serving the profile description overlapped with the container description at/. So putting the profile description in/.metaand have it included in the/response along with the container information was a trick. Okay to let that possibility go, in favour of dropping.metaon containers.csarven commentedon Oct 23, 2017
Not to stop this issue, but upon further thinking about this in context of versioning,
/.metacan be useful, eg. to indicate what is a versioned and if so (un)locked resource, and what is not.csarven commentedon Jan 9, 2019
Issue #1040 should be the successor of the functionality to update containers. If that's in place, the feature to update container description via /.meta can be deprecated.
timbl commentedon Jan 13, 2019
I think (hope) there is a misunderstanding here. These two issues This #547 and the newer #1040 are surely the same function. The .meta file is an internal way in which NSS happens to implement writing triples to a container. The .meta URL is never seen by the client. This issue removed the ability to store arbitrary triples in a Container, #1040 puts it back surely.
csarven commentedon Jan 13, 2019
/.meta URL is "seen" by the client if they write to it, or at the very least, the HTTP headers have a describedBy relation pointing to it.
This issue proposed the removal but it wasn't removed in NSS. It was marked as revisit. The functionality ( write to /.meta, read from /) remains.
As for #1040 , it is different in that it proposes to only interact with the container URI , but yes, writing triples to a container is retained. The main difference is that #1040 ensures that .meta is never really seen (provided that rel="describedBy" for .meta URI in HTTP headers is also dropped).
dmitrizagidulin commentedon Jan 21, 2019
@csarven - I second what @timbl said. These two issues are asking for exactly opposing functionality.
csarven commentedon Jan 21, 2019
@dmitrizagidulin https://gitter.im/solid/node-solid-server?at=5c3d3d3a35350772cf315ca8
dmitrizagidulin commentedon Jan 21, 2019
@csarven Copy that, thanks.
jeff-zucker commentedon Jun 25, 2019
It seems to me that the current behavior of write to /.meta and read in / is very useful for app developers. It allows us to tag photos and music easily in a way that an app can easily retrieve it with a single GET on the container. It supports things like dumping an existing database of photos or music into container .meta files and allowing one-step retrieval of the entire container. Am I missing something about why this is bad? Is it really going to go away? Because, if not, I already have several projects in mind (e.g. dump rhythmbox's SQL to .meta files for each container, upload to pod,). Could someone summarize where this issue now stands? Can we count on the write to /.meta, read in / behavior in the future?
csarven commentedon Jun 25, 2019
The "meta" feature remains. The read/write interface is intended to be through /. Server implementations can decide where to physically read/write "meta" from (behind the scenes) - that's out of spec.
jeff-zucker commentedon Jun 25, 2019
Yes, I understand that the location of the .meta is implementation specific and findable only in the Link header. What I'm unclear on is whether I, as an app developer, can count on the behavior that the container shows triples found in the container's metadata applying either to the container itself or to what the container contains so that we can retrieve metadata on non-RDF resources. I am asking partially because my collaborators and I need to decide if solid-file-client will support viewing and editing .meta files - we don't want to encourage developers to go down a road that is slated to disappear.
csarven commentedon Jun 25, 2019
No, that's not what #1040 proposes. The client does not need to know anything about .meta or discovering .meta separately from the thing it refers to. Everything happens through the resource itself. If you have "meta" about
/foo/, you write to it directly. So, a server does not need to advertise URI2 for writing just so that when URI1 is read it includes stuff from URI2. That's super weird and IMHO, wrong. If URI1 is what we are talking about, interactions happen through that. We don't need weird magic APIs here. HTTP interface is straight forward.jeff-zucker commentedon Jun 25, 2019
What you are saying makes sense for the behavior of the container and its metadata, but I am still not understanding what you propose for resource metadata. Would it also be placed in the container's turtle and editable or would there be separate metadata files for each resource? And if the later, how would we read or write to them without having to find them?