Rethinking syndication #581
Labels
code quality
Making things easier to understand
core
Core indiekit package
help wanted
Extra attention is needed
plugin-syndicator
Syndicator plug-in
question
Further information is requested
Milestone
Syndication is not working. As much as I try to patch over the cracks, fundamental flaws reveal themselves.
Here are a few things I learnt while trying to get syndication working reliably.
mp-syndicate-to
is a directive, not a post propertyMuch like
mp-slug
,mp-photo-alt
and (eventually)mp-destination
do not appear in a posts properties, neither shouldmp-syndicate-to
. As a directive to the Micropub server, it does not need saving in a content store.mp-syndicate-to
in post file #582post.syndicateTo
Should syndication status be stored with posts or separately?
Syndication is flakey. APIs respond with weird errors, go down, or API keys get invalidated; the list is endless. Therefore, syndication needs to be a very asynchronous task.
Rather than try to keep a record of syndication status across different posts, a dedicated
syndications
database could be used.When an incoming request includes
mp-syndicate-to
, we could add the post_id
(not path or URL) to the list of outstanding syndications for that target:This information could be shown in the interface for the syndication endpoint, possibly at some stage allowing for some management, if that turns out to be a need.
Syndication can occur before or after a post is published
Currently, syndication only happens after Indiekit has published a post. One reason for this is that one syndicator, Internet Archive, needs to crawl the generated post HTML, meaning syndication makes sense once there is post URL for it to visit.
Also, while not currently possible, were statuses to contain a back-links, a post would need to be published for that link to work. Maybe this is not a massive problem; it’s unlikely back-links would be clicked on immediately after being tweeted/tooted/published, but it underlines this point.
What if syndication plug-ins could provide methods that are called pre-publication, as well as methods that are called post-publication? Then a syndication plug-in can dictate the most desirable point at which syndication occurs.
Syndication is not a one-time action
Currently, syndication is a one-time write action. What happens if you update or delete a post? Twitter has creation and deletion methods, and Mastodon allows statuses to be created, updated and deleted.
In that respect, syndicator plug-ins could be more similar to content store plug-ins, providing CRUD methods where possible that the Micropub endpoint can call as part of undertaking the respective CRUD Micropub action.
How would this fit in with the above suggestion (a separate database). Would that only be used to record and track syndications that failed (and maybe post-publication syndications)?
Next steps
I will mull over some of these ideas in the coming months. My immediate priority is to simplify when and how data is updated in the database and reflected in files sent to content stores.
The text was updated successfully, but these errors were encountered: