Talk:Requests for comment/Zero architecture

Previous page history was archived for backup purposes at Talk:Requests for comment/Zero architecture/LQT Archive 1 on 2015-07-10.

Hi! I don't quite understand the current status of this work - it sounds like it's done and we should change its current status to Complete & Implemented. Is that so?

Almost, except for the linchpin of ESI support is currently blocked on a Varnish upgrade. The 3.* series lacks the necessary ESI support to make this work, and I believe an upgrade to the 4.* series is in the medium-to-long term plan with Ops.

This post was posted by ABaso (WMF), but signed as ABaso(WMF).

Adam, I'm going to move the RfC status to something showing that the community doesn't need to comment on it anymore; best wishes on finishing the implementation soon. Thank you for the response!

they should be generated using ESI (Edge Side Includes)

The passive voice leaves it unclear what software performs the ESI transclusion (when it's not done by client-side JavaScript). I assume you intend WMF's Varnish layer to do it, not the squid caching layer or the carrier's CDN.

This post was posted by SPage (WMF), but signed as S Page (WMF).

clarified

From RFC

• 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 Zero:
• Zero: 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.

Many developers want to store JSON on-wiki (e.g. User:Yuvipanda/Campaigns namespace proposal#Implementation, so I hope you implement a general-purpose JsonContent with the last bullet in a subclass. As you probably know, Extension:EventLogging implements a JsonSchemaContent type in a Schema: namespace on meta-wiki and provides a global efSchemaValidate() function, useful code to borrow and invoke.

This post was posted by SPage (WMF), but signed as S Page (WMF).

It would be awesome if someone would write a generic schema-based json editor/visualizer for wiki. Our requirements are fairly complex, and involve a number of validation and cleanup steps (like sorting and de-duplicating certain entries), as well as display of additional information such as banners at the bottom and language fallbacks on the right hand side. See meta:Zero:250-99.

"Language dropdown lists vary on X-Subdomain and X-CS" and "Listed high priority languages [, which] are similar to language dropdowns": I don't understand if this is a proposed or existing thing, but it seems to duplicate ULS features in some way; their logic should probably be coordinated, at least when ULS replaces the standard interlanguage wikilinks view (ask Pau)?

Thanks, Nemo. They dropdown list and the listed high priority languages is a feature of the pre-existing Wikipedia Zero's Special:ZeroRatedMobileAccess page (we've made small tweaks since taking on the codebase, but it's largely the same). Will check with Pau about ULS.

This post was posted by ABaso (WMF), but signed as ABaso(WMF).

Hi. Is there a list of Wikipedia Zero's requirements somewhere? From what I can tell, the goal is to provide Wikipedia for free at zero.wikipedia.org. (We already provide Wikipedia for free at www.wikipedia.org, so there's immediately a question of why there's a separate domain.) The amount of overhead to provide this service seems like a bit much, but without knowing the requirements, it's difficult to properly assess.

For example, setting up a lot of infrastructure just so that a small HTML snippet can be dynamic may not be the worth the cost, unless that banner is hugely important to the success of the overall project.

Is there a requirements list somewhere?

I think dfoy would be the best person to talk about requirements, but from what I know, there are some good reasons for it: a) navigating to a zero.* domain always reports free/non-free banner, b) unlike m.* has no images, c) allows carriers to do URL filtering in a more precise way, d) all links get instrumented to ask for "navigate to pay zone" confirmation. At the same time, we are trying to get all new telcos to get m.*, even though we might still be under contractual obligations to provide the zero domain (my suspicions, not hard facts).

MZ, m:Metrics and activities meetings/Quarterly reviews/Wikipedia Zero, 2013-02-20 answers your question, AFAICS.

I am a little concerned about auto-generating Varnish conf, since the VCL used by Zero is shared with mobile web more broadly. Perhaps the VCL should be refactored to pull the Zero-specific bits out and capture them in their own separate file for inclusion in the VCL. There's still potential for auto-generation to do something that will cause some sort of conflict, but at least the auto-generated stuff will be contained.

Updated section to clarify - we are not generating VCL, only a simple text file with IP blocks => Carrier ID mapping. VCL will pull it in and set X-CS header to the found ID, same way as geoIP calculates the country.