Active vs final last modified

[jbfaden]

To provide useful caching to the clients, HAPI servers can report modificationDate for the dataset, which clients can use to manage a cache of previously downloaded data. With an active archive, where data is constantly being added as it is collected, this modificationDate is always being modified. So that clients can effectively cache data, we should consider allowing a "final archive" portion of the data. For example:

finalArchiveStopDate  would be the last date in the archive portion
finalArchiveModificationDate   would be the time stamp used to identify this portion

Another thought would be to allow a growing array of finalArchiveStopDates and finalArchiveModificationDates which would version sections of the data.

Note the finalArchiveModificationDate for a given finalArchiveStopDate would change when new revisions are published, so "final" should not imply unchanging, but changing less often than "modificationDate."

[jbfaden]

Note I'm throwing this out there for discussion, and I don't necessarily think this should be part of the specification.

[rweigel]

Closing because of lack of follow-up.

[jvandegriff]

Notes from 2025-05-12:

• modificationDate - decide about meaning: does it apply just to data (and what if data is added to end, is that still a regular mod?); and what about if the metadata changes?
• current thinking:
  • don't report changes to the JSON headers - the mod time for that can be obtained from HTTP headers for the JSON; this requires servers to be smart about how they set the mod time on JSON info responses - the server needs to track the mod time of info going into the info response so that the mod time on the HTTP header for that info is accurate
  • if there is any revision of any of the numbers that you get back for a previous request, including adding new data or filling in gaps, the mod time should be updated

[jbfaden]

See also #68