Combine preferences callback and track-changes on defining query

[ralfhandl]

Current specification text suggests that preference callback can only be used

• on a GET request to a delta link

This suggests that two requests are necessary for being notified of changes:

• Send defining query with preference track-changes
• Send GET request to delta link with preference callback

Allow combining this into one request:

• Send defining query with both preference track-changes and preference callback

[HeikoTheissen]

It seems problematic that callback is a preference on its own which can appear together with another preference, either respond-async or track-changes. If callback was an attribute of these other preferences, it could appear in both in one request.

[ralfhandl]

Alternative 1: Extend current state

Prefer: track-changes

• return delta link for polling

Prefer: track-changes,callback;url=http://me

• return delta link, callback on changes

Prefer: track-changes;mode=no-delta-link

• don't return delta link, kind of useless

Prefer: track-changes;mode=no-delta-link,callback;url=http://me

• don't return delta link, callback on changes

Problem: can't prefer to have a complicated defining request processed async and get a callback for the async processing and a different callback for the available delta

Alternative 2: Add callback-url attribute to other preferences, optionally deprecate callback preference in combination with these

Prefer: track-changes;callback-url=http://me

• return delta link, callback on changes

Prefer: track-changes;no-delta

• don't return delta link, kind of useless

Prefer: track-changes;no-delta;callback-url=http://me

• don't return delta link, callback on changes, solves Introduce a method for fully automated data replication of small data sets #1962

GET /complicated-collection
Prefer: respond-async;callback-url=http://me/initial,track-changes;callback-url=http://me/delta

[ralfhandl]

Idea: if service doesn't support callback, respond with Preference-Applied and omit the unsupported callback-url.

Unfortunately not supported by the syntax of Preference-Applied.

[ralfhandl]

Add new preferences respond-async-callback and track-changes-callback that can be used combined with the existing and explain all valid combinations.

Note: respond-async is registered without attributes, so we can't (easily) extend it with attributes, which effectively excludes Alternative 2.

[mikepizzo]

I would like to make sure we clarify relationship of the new callback preferences with the existing callback preference.

In particular, is it an error to specify the existing preference with the new preference (which would require the client know which preferences they can provide) or do the new preferences take precedence over the existing preferences (which I think is my preference). And, do we want to deprecate the existing callback preference in favor of the new ones.