Flow/Architecture/Internals


 * Not particularly useful

code resources

 * container.php provides resources.
 * container.php is configuration, includes/Container.php is implementation class
 * uses third-party Pimple to provide lazily-evaluated closures
 * uses third-party Pimple to provide lazily-evaluated closures

actions
Likewise, top-level FlowActions.php, then includes/Actions.php implementation

This configures how different actions work, e.g.


 * moderation actions get logged in Special:Log (log_type)
 * nearly everything gets written to RecentChanges (rc_insert)

permissions: if there's nothing there, it's blocked altogether
 * currently no support for moderation of header


 * button-method needs to die

Links (for queries) and actions (for writes), are outputs. The configuration says "If the change type of a revision is this, then the API output will include URLs for the specified actions. E.g. response to create-header, outputs these links. Even though e.g. 'board-history' isn't used, the page chrome adds the ?action

API post parameters
I edited the header of a new board (not on ), adding some links. After I solved the captcha, the POST was:
 * action=flow

ehcontent=Second try: Creating a header just to see what the API hands back. Links to User:spage, format=json page=User_talk:JunkTest2 submodule=edit-header token=34d7a48e72f868bcd5a6f98372796be6+\ wpCaptchaId=NNN wpCaptchaWord=SEKRIT

API response
The response body, reformatted, for this  action is below. Note how it has the URLs for links and actions that FlowActions.php specifies. The front-end uses (some of) these to create links and buttons in the UI. the  key's HTML, reformatted, is: and this is the HTML that the front-end code inserts into the page. Note that the data-parsoid attribute from parsoid can change at any time, while data-mw contains stable repeatable data. The data-parsoid attribute should generally be ignored.

Caching
Varnish caches output pages for anonymous users (Flow clears this in caches) then Flow stores items in memcached.

Flow has a per-request internal cache of stuff it's already asked for.

All in includes/data/ ObjectManager drives it.

From a list of queries
 * determine cache keys
 * if it finds all the keys, then it returns
 * otherwise goes to "backing store", the database.

The posts that are output map to memcached keys according to index classes, e.g. includes/Data/Index/FeatureIndex.php

ObjectManager objects implement either Find or FindMulti

rowCompactor removes keys you don't need.

Tries to reduce the amount of joins so that we can eventually shard the data.

Example
A topic list query includes/Block/TopicList.php

In general, split into two parts, query and formatter. TopicList also has a paginator deciding what the list is.

Talk:Flow has a workflow identifier, each topic has a workflow identifier.
 * One memcached key for topics in the page
 * trim to a slice of 10 of these
 * Does a MultiGet to get those 10 topics

FormatterRow holds all the information,

may turn out that stuff can't be viewed by user, RevisionFormatter will remove those. Then the pager will

To debug what is cached
purge.php script does the query, but replaces from Hash bag of stuff to memcache bagOfStuff, forcing a repopulation, and then you can examine the keys.

Future
Store entire topics, but then have to filter out moderated stuff the current user isn't supposed to see.

Listeners
Updates of links, IRC updates, etc. are handled by listeners on

Parsoid directory
Extractors find references in the Parsoid output.

Core doesn't know about parsoid output, so we have to get stuff (links, etc.) out of Parsoid and hand it to core. Eventually our code should be useful to Parsoid extension