From e443085c525db1226b0c3123076fcde244ae5f52 Mon Sep 17 00:00:00 2001
From: Brent Simmons <brent@ranchero.com>
Date: Wed, 8 Apr 2020 17:45:32 -0700
Subject: [PATCH] Write Technote on Retention Policy.

---
 Technotes/RetentionPolicy.markdown | 72 ++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 Technotes/RetentionPolicy.markdown

diff --git a/Technotes/RetentionPolicy.markdown b/Technotes/RetentionPolicy.markdown
new file mode 100644
index 000000000..c86799409
--- /dev/null
+++ b/Technotes/RetentionPolicy.markdown
@@ -0,0 +1,72 @@
+# Retention Policy
+
+This is a user interface issue, primarily — what articles should be displayed to the user?
+
+This article answers that question, and it describes how the decisions are implemented.
+
+And, at the end, there’s a special note about why we have limits at all.
+
+## Web-Based Sync Systems
+
+When used with Feedbin, Feedly, and other syncing systems, NetNewsWire should show the same unread articles that the user would see in the browser-based version. (The unread counts would necessarily be the same in NetNewsWire and on the web.)
+
+It should also show the exact same starred items.
+
+It does *not* have to show the exact same read items. Instead, it will show read items that arrived locally in the last 90 days.
+
+### Database Queries
+
+Most queries for articles should include this logic:
+
+* If an article is userDeleted, don’t show it
+* If an article is starred or unread, show it no matter what
+* If an article is read, and status.dateArrived < 90 days ago, then show it
+
+### Database Cleanup
+
+Database cleanups to do at startup:
+
+* Delete articles from feeds no-longer-subscribed-to, unless starred
+* Delete read/not-starred articles where status.dateArrived > 90 days go (because these wouldn’t be shown in the UI)
+* Delete statuses where status is read, not starred, and not userDeleted, and dateArrived > 180 days ago, and the associated article no longer exists in the articles table.
+
+We keep statuses a bit longer than articles, in case an article comes back. But we don’t keep most statuses forever.
+
+## Local and iCloud Accounts
+
+NetNewsWire should show articles that are currently in the feed. When an article drops off the feed, it no longer displays in the UI.
+
+The one exception is starred articles: as with sync systems, starred articles are kept forever.
+
+### Database Queries
+
+Most queries for articles should include this logic:
+
+* If an article is userDeleted, don’t show it
+* If an article is starred, show it no matter what
+
+### Database Cleanup
+
+Database cleanups to do while running:
+
+* When processing a feed, delete articles that no longer appear in the feed — unless a feed comes back empty (with zero articles); do nothing in that case
+
+Database cleanups to do at startup:
+
+* Delete articles from feeds no-longer-subscribed-to, unless starred
+* Delete statuses where not starred, not userDeleted, and dateArrived > 30 days ago, and the associated article no longer exists in the articles table.
+
+We keep statuses a bit longer than articles, in case an article comes back. (An article could come back when, for example, a publisher reconfigures their feed so that it includes more items. This could bring back articles that had previously fallen off the feed.)
+
+## Why Do We Have Limits At All?
+
+Most people don’t want NetNewsWire to just keep holding on to everything forever, but a few people do.
+
+And that’s understandable. It’s pretty cool to have a personal backup of your favorite parts of the web. It’s great for researchers, journalists, and bloggers.
+
+But the more articles we keep, the larger the database gets. It’s already not unusual for a database to become 1GB in size — but we can’t let it grow to many times that, because it will:
+
+* Make NetNewsWire unacceptably slow
+* Take up an inordinate amount of disk space
+
+So we need to have limits. The point of NetNewsWire is to keep up with what’s new: it’s *not* an archiving system. So we’ve defined “what’s new” expansively, but not so expansively that we don’t have a definition for “what’s old.”