Clients need a reliable and efficient way to determine whether any resource within a container hierarchy has changed and when, and ideally what may have changed, without having to traverse the entire tree on every sync.
(Aside: this may also need or want to incorporate if and what auxiliary resources of resources within a container hierarchy changed.)
As it stands, while the Solid Protocol expects servers to include the Last-Modified header in the response, update of that value is left to the discretion of the server, and there is no requirement that the container's Last-Modified also reflects a change that may have happened somewhere within a given container hierarchy ( https://solidproject.org/TR/2024/protocol-20240512#container-last-modified-comparison ). So, this issue is to revisit this topic since it was put aside at the time.
There may be a range of solutions with varying complexity and cost, from always requiring a server to use most up to date modified value (and the distinction between the container resource itself and a resource within a container hierarchy), to client's detecting server's capabilities, to client sending a preference signal, to sync or async updates (notifications), to querying, to... whatever. So, e.g., potentially using:
Last-Modified headerPrefer headerPreference-Applied headerDepth headerPROPFIND headerHEAD or GET methodsQUERY method
Re QUERY, e.g.:
QUERY /
Content-Type: application/sparql-query (or whatever)
Prefer: return=deep-last-modified (or whatever)
SELECT ?resource ?modified (or whatever)
...
Clients need a reliable and efficient way to determine whether any resource within a container hierarchy has changed and when, and ideally what may have changed, without having to traverse the entire tree on every sync.
(Aside: this may also need or want to incorporate if and what auxiliary resources of resources within a container hierarchy changed.)
As it stands, while the Solid Protocol expects servers to include the
Last-Modifiedheader in the response, update of that value is left to the discretion of the server, and there is no requirement that the container's Last-Modified also reflects a change that may have happened somewhere within a given container hierarchy ( https://solidproject.org/TR/2024/protocol-20240512#container-last-modified-comparison ). So, this issue is to revisit this topic since it was put aside at the time.There may be a range of solutions with varying complexity and cost, from always requiring a server to use most up to date modified value (and the distinction between the container resource itself and a resource within a container hierarchy), to client's detecting server's capabilities, to client sending a preference signal, to sync or async updates (notifications), to querying, to... whatever. So, e.g., potentially using:
Last-ModifiedheaderPreferheaderPreference-AppliedheaderDepthheaderPROPFINDheaderHEADorGETmethodsQUERYmethodRe
QUERY, e.g.: