Flow/Architecture/Futures

Store topic as single HTML document

 * Status
 * we have a proof-of-concept patch


 * Pros
 * Gabriel Wicke likes it
 * fits well with Requests for comment/Storage service
 * potentially higher performance, one storage read replaces lots of updates
 * much better scaling model than ExternalStore's poor sharding model.


 * Cons
 * wiki text can't vary per user
 * lot of work to update individual posts within the topic
 * delete/suppress/hide individual posts more complicated

Use content handler for Flow boards

 * Pros
 * natural way to determine if a page is a Flow board
 * may be natural way to get link table updates


 * Minuses
 * it's only an integration point, it doesn't give us anything, we have to write all the code

Use a dedicated namespace and content handler for Flow topics
e.g. workflow:rs9kbf8vtldmbjm3
 * Pros
 * natural wiki link


 * Cons

Move Flow to a service
API moves to the service, PHP only does the rendering.

So the wiki page/ContentHandler would just be the identification of the item and the integration of it with MediaWiki.

Note the new API in the front-end rewrite (returning different information to the current calls) should be sufficient for mobile apps, but it's not what Gabriel is talking about.

Pin the Flow database to a particular wiki, e.g. "meta"

 * Pros
 * natural way to support links tables and such.

Allow wikitext on Flow board page
Like LQT you continue to see the wikitext of a Flow-enabled page.


 * Pros
 * replaces Flow board header, just edit the page
 * categorization, whatlinkshere, etc. in the board "header" all just work
 * some bots keep working


 * Cons
 * performance
 * complexity - stuff in the board