You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From propershark/timetable_cpp#18, all responses from Timetable should include a version number indicating the version of the data that it is sourcing information from. When the backing data changes, the version number will change as well.
The proposal from that issue is to use a Last-Modified-esque timestamp for the version number to avoid ever having collisions.
The text was updated successfully, but these errors were encountered:
Thinking about it a little more, it would probably be good to include a provider_id or similar and apply this to all responses from both RPCs. That way, providers can be cached independently by a client, and they can invalidate their caches only for the providers whose version has changed.
This follows well with the suggested format of the version number as meta information in a wrapping hash, similar to most REST APIs:
From propershark/timetable_cpp#18, all responses from Timetable should include a version number indicating the version of the data that it is sourcing information from. When the backing data changes, the version number will change as well.
The proposal from that issue is to use a
Last-Modified
-esque timestamp for the version number to avoid ever having collisions.The text was updated successfully, but these errors were encountered: