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
Deferred work items from eng review and design discussions.
4
+
5
+
## GDELT as Third News Provider
6
+
7
+
**What:** Add GDELT (Global Database of Events, Language, and Tone) as a third news provider.
8
+
9
+
**Why:** Diversifies beyond Bing+Google. GDELT covers global events with no rate limiting, providing a fallback that doesn't depend on commercial search engines.
10
+
11
+
**Pros:** Better geographic coverage, no rate limiting, tests the Protocol's extensibility beyond RSS.
12
+
13
+
**Cons:** Returns JSON (not RSS), so the `NewsProvider` Protocol needs a `fetch_entries()` method or a JSON-to-FeedEntry adapter. Non-trivial change to the provider interface.
14
+
15
+
**Context:** Design doc Open Question #1. The current `build_feed_url()` + `fetch_feed()` pattern only works for RSS providers. GDELT would need either a new Protocol method or an adapter that converts JSON responses to `FeedEntry` objects.
**What:** Add user-facing config (`config.yml`) to set provider priority order and enable/disable providers globally or per topic.
22
+
23
+
**Why:** Power users on restricted networks (China, Russia) may need to disable Google entirely. Per-topic pinning lets users optimize provider choice for specific topic domains.
24
+
25
+
**Pros:** Maximum flexibility for self-hosted users on restricted networks.
26
+
27
+
**Cons:** Adds config surface area. Violates "user doesn't think about it" for the common case. Only valuable with 3+ providers.
28
+
29
+
**Context:** Design doc Approach C, rejected for the initial multi-provider PR. Auto-routing handles the common case. Only worth building when the provider ecosystem grows.
30
+
31
+
**Depends on:** Multi-provider PR + at least one more provider (e.g. GDELT).
0 commit comments