Deep change detection for containers

コンテナの Last-Modified の比較に関する Solid Protocol セクションから始め、続いて一覧にある header、method、query、notification の各アプローチを比較します。プロジェクトが deep-change-detection の具体的な方向性について合意し、その結果として必要になるプロトコル要件または仕様変更を記録できれば完了です。

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 header
• Prefer header
• Preference-Applied header
• Depth header
• PROPFIND header
• HEAD or GET methods
• QUERY 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)
...