Review potential for using RSS feeds

[DeniseColbert]

This may not be in the correct place, but can be moved/new stories made on relevant boards if we move forward with it/elements of it.

[ghost]

@DeniseColbert @richpomfret

Multiple publication/subscription models could be applied in different contexts:

• JSON:API
• RSS / RSS2
• WebSub / PubSubHubbub

I see high utility in supporting RSS and WebSub for all documents produced by Content Management Systems (CMS's) and providing summary information using JSON:API with the following optional query variables: (note that implementation should support use of multiple query variables)

• (default) Count of all records
• interval= Count new records added since interval (day, week, YYYY-MM, YYYY-MM-DD)
• location= Count of records associated with "Chapman code" or "place ID"
• type= (baptism/birth|burial|marriage) Count of records of type

Building on the usefulness of the JSON:API summary functionality, syndicated feeds announcing the addition of records could be published with RSS and WebSub - e.g.

As of {DATE_TODAY} we have added {RECORD_COUNT_ADDED} new records at {SITE_NAME},
for a total of {RECORD_COUNT_TOTAL} records specific to {PLACE_NAME}.

This would allow local genealogical societies and other record consumers to be made aware of substantial additions and reduce need for manual notification processes.

Historically I have been able to add these types of functionality with very little modification to existing search and output code, so I would expect the addition of this functionality to be relatively low-hanging fruit for the organization.

In an ideal implementation, a unified JSON:API provider could also be used to serve up details on specific records and search queries via Javascript (with an IFRAME fallback for users with Javascript disabled), allowing for the separation of concerns between content management and record maintenance/search utilities.

The unified JSON:API provider could additionally be used, with authentication, by third-parties which have an interest in genealogical data with a "free tier" rate limit preventing automated harvesting of records (e.g. limit # of queries to 5% of # of records added, on average, each day) and premium API access tiers which would allow third-parties to access records at a per-record fee or on a monthly subscription plan.

[ghost]

Assigning to @DeniseColbert for follow-up (happy to draft a formal specification if that'd be helpful)

[DeniseColbert]

Thanks @arswright-alt-uk 👍
Have assigned @PatReynolds & @richpomfret for their attention.

[monochromecyan]

Good to keep this I would say.