Follow-up from #53 (PR #123), which built the collaborative freshness poll.
The gap
POST /api/lists/{id}/data/versions is a version-diff endpoint: the client sends rowVersions
for the rows it is holding, and the server answers with changed (those rows, if stale) and
deleted.
By construction it can only report on rows the client already knows about. A row that another
collaborator inserts has no version for us to quote, so it never appears in changed and the
grid does not learn about it. #123 appends defensively if a changed row arrives that we were not
holding, but insertions do not arrive at all.
Effect: two people editing the same list see each other's edits and deletions live, but not
each other's new rows, until someone pulls to refresh.
Options
- Client-side: have the poll periodically (much less often than the 10s beat — say every Nth
quiet beat) re-read GET /api/lists/{id}/data page 1 and merge in unseen ids. Cheap to build,
but it is exactly the whole-table refetch the versions endpoint exists to avoid.
- Server-side (better): have the versions response include an
inserted[] array, or a list-level
row-count/high-water mark the client can compare against cheaply. Worth asking the owner whether
the first-party web grid has this problem too, or whether it solves it some other way.
Option 2 is the right fix if the endpoint can grow it; option 1 is the fallback.
Context
version is now plumbed through RowDto/ListRow by #123, which is also the prerequisite for the
other half of collaborative editing — If-Match + { changes, expect } per-field deltas and
409 version_conflict handling — which remains unimplemented.
Follow-up from #53 (PR #123), which built the collaborative freshness poll.
The gap
POST /api/lists/{id}/data/versionsis a version-diff endpoint: the client sendsrowVersionsfor the rows it is holding, and the server answers with
changed(those rows, if stale) anddeleted.By construction it can only report on rows the client already knows about. A row that another
collaborator inserts has no version for us to quote, so it never appears in
changedand thegrid does not learn about it. #123 appends defensively if a changed row arrives that we were not
holding, but insertions do not arrive at all.
Effect: two people editing the same list see each other's edits and deletions live, but not
each other's new rows, until someone pulls to refresh.
Options
quiet beat) re-read
GET /api/lists/{id}/datapage 1 and merge in unseen ids. Cheap to build,but it is exactly the whole-table refetch the versions endpoint exists to avoid.
inserted[]array, or a list-levelrow-count/high-water mark the client can compare against cheaply. Worth asking the owner whether
the first-party web grid has this problem too, or whether it solves it some other way.
Option 2 is the right fix if the endpoint can grow it; option 1 is the fallback.
Context
versionis now plumbed throughRowDto/ListRowby #123, which is also the prerequisite for theother half of collaborative editing —
If-Match+{ changes, expect }per-field deltas and409 version_conflicthandling — which remains unimplemented.