Define a top-level field that describes the feed's update frequency

[KyNorthstar]

Motivation

Some feeds, like Twitter, might update by the second. Some others, like a typical blog, might update daily. Perhaps a podcast only updates once a week. Others still might even only update once a year. Some utility APIs generate infinite feeds on-demand and so update frequency would not be detectable.

The readers that support JSONFeed might not want to check every feed at the same rate; choosing something arbitrarily will inevitably leave some feeds updating too slowly and others too rapidly. Attempting to use algorithms, heuristics, or AI to determine an appropriate rate per-feed might result in missed posts if the feed suddenly becomes more active, or wasted polls if it suddenly becomes inactive, or worst might end up using far too many system resources checking an infinite feed.

Ideas

Here are my ideas, in no particular order. Feel free to shoot them down, improve on them, or propose entirely new ones:

Recommended number of seconds between checks

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Podcast",
  "update_delay" : 86400
}

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Twitter",
  "update_delay" : 60
}

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Blog",
  "update_delay" : 3600
}

Recommended number of checks per day

... or per whatever unit. I chose "per day" for the examples:

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Podcast",
  "update_frequency" : 1
}

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Twitter",
  "update_frequency" : 1440
}

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Blog",
  "update_frequency" : 12
}

A strictly-defined enumeration

For instance, "per-second", "hourly", "daily", etc.

This one might behave much more differently than the others, since it's not a strict recommendation. For that reason, I kinda prefer this; you say "I update this often" and the reader might check twice as often (or so) just in case you post an important update.

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Podcast",
  "update_frequency" : "weekly"
}

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Twitter",
  "update_frequency" : "per-minute"
}

{
  "version" : "https://jsonfeed.org/version/2",
  "title" : "My Blog",
  "update_frequency" : "daily"
}

Priority

The presence of this field should be seen as a suggestion, and should be overridden by the expired field.

Fallback

If implemented, this should not be a required field. If no frequency is specified, then some arbitrary rate like once every few minutes should probably be used, or the client can infer the frequency using its own algorithms.

[baldurbjarnason]

Doesn't WebSub support cover a lot of this? That is, any app or system that checks feeds often enough to need this would be using WebSub to get updates pushed to them anyway?

Not saying that this wouldn't be useful information to have in principle, just that WebSub lets feed consumers sidestep this problem for a lot of use cases.

[KyNorthstar]

@baldurbjarnason I agree that the consumer can and should be able to override this if preferred, but shouldn't be required to infer it if the provider has better knowledge of how often it updates. I think it's best to allow the provider to have a standardized way of communicating this, in case the consumer would like to take advantage of it.

[JKingweb]

I think it's best to allow the provider to have a standardized way of communicating this, in case the consumer would like to take advantage of it.

We already have Expires and Cache-Control: max-age at the HTTP level, for what it's worth.

[KyNorthstar]

@JKingweb Is JSONFeed dependent on HTTP? As far as I knew, they're independent. If being transmitted over HTTP is a requirement of JSONFeed, then that might be worth considering, but then at that point why not pack more info into the HTTP headers, like Content-Disposition: JSONFeed; name="My Example Feed", rather than have it in the JSONFeed file itself?