Hey all,
A quick update from me about the work of the Asynchronous Content Fragments
working group.
*TL;DR*
We're meeting each week to talk about adding async content support to MW.
This week we discussed possible upper-level use cases, with initial
thoughts documented on this page
<https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Asynchronous_content_fragments#Draft_use_cases_and_their_sources>.
Comments welcome!
*Context*
The overall goal <https://phabricator.wikimedia.org/T282585> is to explore,
decide on, and build a way to include asynchronously-available content
fragments in MediaWiki pages, to allow new forms of content (like
Wikifunctions) and a faster, less tightly-coupled design for MediaWiki
overall. The working group (Subbu and C. Scott from Content Transformation,
Tim from Platform, Moriel from Architecture, and me from Abstract
Wikipedia) exists to turn the Decision Statement Overview
<https://docs.google.com/document/d/1kU7a5V-exubbXcyyMA0jKlqioQkoRptexgoWrZovnpE/edit#heading=h.5tjhe7ka6tr7>
agreed by the Technical Decision Forum into a set of options for
implementation
<https://www.mediawiki.org/wiki/Technical_Decision_Forum/Technical_Decision_Making_Process#Research_and_Prototyping_Stage_(Timeboxed_with_check-ins_every_two_weeks)>
(as will be finally agreed in a Decision Record).
*Work this week*
This week we discussed some use cases that I proposed. There was a lot of
talk around the differing needs in what readers, most API consumers, search
engines, *etc.* will want vs. what editors (and other logged-in users) will
need to be effective.
In particular, we considered the need for anti-abuse features,
Notifications, Recent Changes and Watchlist entries to all trigger
immediately (as is current behaviour) despite not having the full result
yet, and then needing the final renders to update wherever they're stored.
This will be complicated, and vary by specific use case. For example the
product need for immediacy will be very high and second results not wanted
(e.g. talk page notification e-mails should be sent immediately and not
wait, but also not be duplicated later); in others, it will be lower and so
things can wait a little bit for some things (e.g. link notifications can
wait a few minutes).
We also talked about the need for having default values, placeholders,
timeouts, and handling errors, and whether that should be controlled by
MediaWiki centrally or if each fragment provider could be synchronously
called to provide default/placeholders as needed.
Much more of this will be discussed next week.
Hope this is of interest. If you have thoughts or comments, please do let
us know on the discussion page
<https://www.mediawiki.org/wiki/Talk:Abstract_Wikipedia_team/Asynchronous_content_fragments>
or directly.
Yours,
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
A quick update from me about the work of the Asynchronous Content Fragments
working group.
*TL;DR*
We're meeting each week to talk about adding async content support to MW.
This week we discussed possible upper-level use cases, with initial
thoughts documented on this page
<https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Asynchronous_content_fragments#Draft_use_cases_and_their_sources>.
Comments welcome!
*Context*
The overall goal <https://phabricator.wikimedia.org/T282585> is to explore,
decide on, and build a way to include asynchronously-available content
fragments in MediaWiki pages, to allow new forms of content (like
Wikifunctions) and a faster, less tightly-coupled design for MediaWiki
overall. The working group (Subbu and C. Scott from Content Transformation,
Tim from Platform, Moriel from Architecture, and me from Abstract
Wikipedia) exists to turn the Decision Statement Overview
<https://docs.google.com/document/d/1kU7a5V-exubbXcyyMA0jKlqioQkoRptexgoWrZovnpE/edit#heading=h.5tjhe7ka6tr7>
agreed by the Technical Decision Forum into a set of options for
implementation
<https://www.mediawiki.org/wiki/Technical_Decision_Forum/Technical_Decision_Making_Process#Research_and_Prototyping_Stage_(Timeboxed_with_check-ins_every_two_weeks)>
(as will be finally agreed in a Decision Record).
*Work this week*
This week we discussed some use cases that I proposed. There was a lot of
talk around the differing needs in what readers, most API consumers, search
engines, *etc.* will want vs. what editors (and other logged-in users) will
need to be effective.
In particular, we considered the need for anti-abuse features,
Notifications, Recent Changes and Watchlist entries to all trigger
immediately (as is current behaviour) despite not having the full result
yet, and then needing the final renders to update wherever they're stored.
This will be complicated, and vary by specific use case. For example the
product need for immediacy will be very high and second results not wanted
(e.g. talk page notification e-mails should be sent immediately and not
wait, but also not be duplicated later); in others, it will be lower and so
things can wait a little bit for some things (e.g. link notifications can
wait a few minutes).
We also talked about the need for having default values, placeholders,
timeouts, and handling errors, and whether that should be controlled by
MediaWiki centrally or if each fragment provider could be synchronously
called to provide default/placeholders as needed.
Much more of this will be discussed next week.
Hope this is of interest. If you have thoughts or comments, please do let
us know on the discussion page
<https://www.mediawiki.org/wiki/Talk:Abstract_Wikipedia_team/Asynchronous_content_fragments>
or directly.
Yours,
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>