Flow/Architecture/Futures
< Flow | Architecture
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on any information on this page. |
Store topic as single HTML document edit
- Status
- we have a proof-of-concept patch Gerrit change 118238
- 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
ContentHandler edit
Use content handler for Flow boards edit
- 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 edit
e.g. workflow:rs9kbf8vtldmbjm3
- Pros
- natural wiki link
- Cons
Move Flow to a service edit
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" edit
- Pros
- natural way to support links tables and such.
Allow wikitext on Flow board page edit
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