Zero is rapidly growing, but its architecture is falling behind, and needs
to be revised.
*== Zero Partner Requirements ==*
* Support both smart phones (full JavaScript support) and feature phones
(limited HTML/no js support)
* Show carrier-specific, language-specific banner
* Allow carriers to select what features are zero-rated: images and list of
languages
* Ask for user confirmation when navigating away from zero (images,
non-zero languages, external sites)
*== Technical Requirements ==*
* increase Varnish cache hits / minimize cache fragmentation
* Set up and configure new partners without code changes
* Use partner-supplied IP ranges as a preferred alternative to the geo-ip
database for fundraising & analytic teams
*== Current state ==*
Zero domain requests set X-Subdomain="ZERO", and treat the request as
mobile. The backend uses X-Subdomain and X-CS headers to customize result.
The cache is heavily fragmented due to its variance on both of these
headers in addition to the variance set by MobileFrontend extension and
MediaWiki core.
*== Proposals ==*
In order to reduce Zero-caused fragmentation, we propose to shrink from one
bucket per carrier (X-CS) to three general buckets:
* smart phones bucket -- banner and site modifications are done on the
client in javascript
* feature phones -- HTML only, the banner is inserted by the ESI
** for carriers with free images
** for carriers without free images
*=== Varnish logic ===*
* Parse User-Agent to distinguish between desktop / mobile / feature phone:
X-Device-Type=desktop|mobile|legacy
* Use IP -> X-CS lookup (under development by OPs) to convert client's IP
into X-CS header
* If X-CS && X-Device-Type == 'legacy': Use IP -> X-Images lookup
(same
lookup plugin, different database file) to determine if carrier allows
images
Since each carrier has its own list of free languages, language links on
feature phones will point to origin, which will either silently redirect
or ask for confirmation.
*=== ZERO vs M ===*
Even though I think zero. and m. subdomains should both go the way of the
dodo to make each article have just one canonical location (no more
linking & Google issues) , this won't happen until we are fully migrated
to Varnish and make some mobile code changes (and possibly other changes
that I am not aware of).
At the same time, we should try to get rid of ZERO wherever possible.
There are two technical differences between m & zero: zero shows a link to
image instead of the actual image, and a big red zero warning is shown if
the carrier is not detected. There is also an organizational difference --
some carriers only whitelist zero, some - only m, and some -- both zero
& m subdomains.
This
spreadsheet<https://docs.google.com/spreadsheet/ccc?key=0As-T7jJ1slQGdDd…
shows
all configurations we allow, and how we handle them at the moment. Each
case requires a different handling, so proposals are listed there.
In general, we should manipulate image links in M for carriers who don't
allow them, and always redirect ZERO to M unless M is not whitelisted, in
which case convince carrier to change their whitelist.