Requests for comment/Zero architecture

Current Architecture

 * Varnish uses a set of IP blocks to determine carrier and sets headers
 * Very inefficient - linear search through all blocks on each mobile request


 * Zero extension shows carrier-specific banner based on the header
 * Zero and mobile extensions need to be decoupled


 * Zero Configuration is done on two en:MediaWiki:... pages
 * Partners cannot make changes themselves - must go through managers and developers
 * ''Settings are hosted on English Wikipedia instead of meta
 * The process is error-prone, there is no validation of any sorts

Partner Configuration

 * Zero extension configurations will be stored as wiki pages in JSON format, one page per partner.
 * Config pages will reside on meta-wiki, in a dedicated namespace ZeroConfig:
 * ZeroConfig namespace will be writable only by people in a dedicated security group
 * Custom content-handler will validate json structure on Save, and invalidate any related caches.
 * Custom visualizer will show settings, duplicate/inefficient IP ranges, banner visualization, etc
 * As a further improvement, the config page could have a dedicated form editor to simplify changes by the partner.


 * TBD: PARTNER name might be localizable, and might be a link to custom URL
 * TBD: Allow HTML blob instead of banner+style

Zero extension

 * The extension will get the JSON blob from the meta page  with an API call, process and verify it, and cache the result in memcached (Key = 'zero-config-' + ID). The ID will be taken from the X-CS header (set by Varnish).
 * Updating a ZeroConfig page will trigger a memcached reset for that ID

Banners
Ideally, due to banners being very small HTML blobs, they should be generated using ESI (edge side include). The only concern is what would be the performance impact, which we really don't know.

In case ESI proves to be too costly, we could try to implement it similar to Central Notice ext for JavaScript-capable clients, and use ESI only for the older ones. Varnish should be able to determine this based on the user agent. JavaScript does not have access to the response header's X-CS ID unless it was an AJAX call, so the client makes an AJAX HEAD or an empty valued GET request to get X-CS header, followed by a request to get carrier-specific JSON settings. We could even make a small API module to return only the needed HTML portion, without other settings like IP blocks (check if Varnish caches API calls). Both AJAX calls should be highly cacheable, hence only the HTML will be requested on subsequent calls.

Varnish

 * See related RT ticket


 * A (semi?-)automated script will iterate through all pages in ZeroConfig namespace, validate them, and extract the IP blocks.
 * A simple text file is created and uploaded to the servers
 * Varnish extension, similar to GeoIP, will load the config file and do an IP to ID lookup:
 * - fast search among IP ranges to get carrier's ID (name of the page in the ZeroConfig namespace)