Split Feed model

[twm]

Much like Article in #415, the Feed model mixes server-set and client-set fields. Unlike that issue the primary concern here is lost updates.

Server-set fields

• url — may be updated
• next_check, last_checked, last_changed — timestamps
• error
• etag, last_modified, digest
• feed_title, site_url — feed metadata

Client-set fields

• url — entered by the user
• created, deleted
• user_title

Server- and client-set fields

• all_count
• unread_count
• fave_count

Proposed changes

Split into a few models:

Feed

Defines a feed to check. Contains the client-set fields.

The url field contains the URL originally entered by the user.

FeedState

Contains the server-set fields.

The current_url field contains the URL after persisting any permanent redirects.

FeedCounts

Contains all_count, unread_count, and fave_count. Maintained exclusively by triggers?

[twm]

Perhaps instead:

Proposed changes

Feed

Defines a feed to check. Contains the client-set fields, plus next_check.

FeedPoll

Represents one poll of the feed.

Fields:

• date — replaces Feed.last_checked
• changed — boolean, replaces Feed.last_changed
• error, etag, last_modified, digest — as the Feed fields
• resolved_url — URL after any HTTP redirects

Lifecycle:

• Created upon completion of a poll.
• They are retained for a limited time (366 days?) for visualization/debugging purposes
• The most recent FeedPoll (if any) is consulted when polling the new feed

[twm]

(I think that I am thinking to hard about this. Lost updates were a concern when Yarrharr was an SPA and I was looking at syncing the full state, but it's just not that likely for an SSR app with a low rate of change.)