solid-client doesn’t (currently) support that, so you could file a feature request. That said, it would be good to know what you’d want to use it for, as there’s no predefined structure for that ETag, and I’m not even sure if a server is required to have one in the first place (I think it’s not).
An ETag for a specific Thing is not possible by definition; they apply to a Resource as a whole.
^^ That’s for the resource, not the thing. AFAIK etags are required (because conditional requests are required) and all servers send them. Trinpod has a mechanism to track things at the thing level, but you’d have to ask @gibsonf1 if that has to do with etags.
I’m looking at implementing conflict resolution between a list of Things on the Solid server and the list in the local App incase the remote data has changed between the last two saves. I’m going to try using modified_datetime for now as I hope that will be fairly unlikely to have the same value. i.e.
there are a list of things in a .ttl file.
one of these things has a modified_datetime of X
user A and user B both fetch the thing, record its initial modified_datetime, and then they both modify it, setting a new modified_datetime.
user B is the first to request to save it back: first they fetch the data again, observe the modified_datetime is the same, and save it. However as the app is using client side generated datetime stamps, if user B’s clock is slow then they might save the object with the same modified_datetime
meanwhile user A goes to save. Like user B their app first fetches the data, observes the modified_datetime is equal to that when they first fetched the item, and silently overwrites user B’s data with their own.
Now I think that edge case is unlikely (I hope) so that technical solution is the one I am going for. However if there was a thing level hash provided by Solid I would also check that.
I should have noted in the other thread that a trivial way of getting atomic transactions is to group objects in one resource and replace the entire resource at once.
In principle if you wanted ETags for each thing you could also store one thing per resource.
A peculiarity of allowing data interoperability is that another app could modify your data in a way that doesn’t respect this kind of metadata.
I would therefore definitely use Etags on the resource, because that is provided by the server. Append-only permissions for some resources and client-side conflict resolution are probably also part of the solution.
Beyond that, any solution you come up with should probably be tested against the possibility of third party changes.
This is definitely an area that’s in flux.
One thing to note is that it’s already possible to ask the server to reject a request if it conflicts with existing data. Specifically, if you send a PATCH request stating which Triples to delete and which to insert, then the server should reject the request if the Triples to delete don’t exist. This is what @inrupt/solid-client does for example, if you modify an existing SolidDataset.