The collection timestamp is updated if an item is added or removed, so
if you're storing the list of collections locally you should only need
to process collections up until you hit a cached dateModified (so likely
only one collections request). Unfortunately you would have to retrieve
all items in each modified collection, but you could use content=none if
you already have the full item data.
> If there was a possibility to get one list of all items in the user's
> database and have for each item a list of all collections it belongs
> to (as part of the item's XML data), this would be much better. Then,
> a sync would only use data in the magnitude of O(#Items).
We'll consider this.
If we put it in the JSON then it would have to be passed back, like
tags, with writes. The alternative would be putting it in the Atom
content, which would maintain the conceptual difference apparent to
users and avoid duplicating the existing RESTful methods for modifying
collection membership. I don't have a strong preference.
> Another question, related to that: if an item gets added to a
> collection (or tagged), does the item's "updated" timestamp change? If
> this were the case, it would also be helpful, because I could at least
> stop fetching items for each collection if I encounter an item that I
> already have with the current data + collection data in my database.
Collection and tag changes do not currently affect the item's timestamp.
This makes for quicker syncing by Zotero itself (which doesn't use the
API for syncing), but there'd be a number of benefits, including the one
you mention, so we might be changing this soon.
> Ideally both things could be combined (reference to collections within
> the data for each item + change timestamp on collection change). Then
> an app could only fetch the items changed since the last sync and be
> done with it.
We'll see what we can do here. The API is currently not particularly
well suited for syncing�among other things, it's not possible to handle
collection-item removals or item deletions without doing full scans�but
we know that offline syncing is a desirable use case, and we'll try to
make it easier for apps to achieve this going forward.