Wikitech-l May 2013

wikitech-l@lists.wikimedia.org

158 participants
192 discussions

Re: [Wikitech-l] Wikitech-l Digest, Vol 118, Issue 102
by anton.bolfing＠access-for-all.ch 31 May '13

31 May '13

Besten Dank für Ihre Nachricht. Ich bin bis am Montag, dem 24. Juni 2013 abwesend und kann Ihre Nachricht erst ab dann wieder bearbeiten. Ihre Email wird nicht weitergeleitet. Beste Grüsse Anton Bolfing ************************************************************************************************************ Thank you for your message. I'm out of office until Monday, June 26. I will not respond to your email until then. Best regards Anton Bolfing

1 0

ZERO architecture
by Yuri Astrakhan 31 May '13

31 May '13

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-T7jJ1slQGdDd3WjhkVmk5SWc5OE…> 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.

3 3

Can we kill $wgPasswordSalt
by Daniel Friesen 31 May '13

31 May '13

It would be nice to kill off $wgPasswordSalt if we could (the ability to set it to false that is). This setting controls whether we use a salted password algorithm or an unsalted one. Basically making something somewhat secure almost completely insecure. This setting appears to exist to make it possible for auth plugins on other pieces of 3rd party software to login using MediaWiki accounts by directly accessing MediaWiki's database but not bothering to understand any of MediaWiki's password algorithms. A fairly dubious rationale to exist IMHO. The current documentation on the setting is also complete and totally false. It says "For compatibility with old installations set to false.", but at this point this has absolutely nothing to do with compatibility. Frankly even if we do have any sort of remaining incompatibility I'd bet it would be fairly trivial to actually solve (eg: For ancient password hashes just try both ancient algorithms instead of just one). -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

5 4

Using Skin system as a beta development environment
by Jon Robson 30 May '13

30 May '13

In my short time at the Foundation I've seen various problems which have risen due to communication problems between seasoned wikipedia editors, WMF teams and volunteer developers. Echo comes to mind as does the mobile photo upload feature my team designed. It strikes me that the skin system would lend itself beautifully to bridging this communication gap between developers and editors. class SkinVectorBeta extends SkinVector { public function initPage( OutputPage $out ) { parent::initPage( $out ); $out->addModules( array( 'echo', 'visualeditor' ) ); } } Any interested editors could enable this skin through user preferences and be able to see exactly what new features are in the pipeline. Is there any reason we don't currently do this in favour of various experiments and then a sudden push to production which tends a lot of the time to result in a heated Village Pump discussion?

4 4

Re: [Wikitech-l] Wikitech-l Digest, Vol 118, Issue 101
by anton.bolfing＠access-for-all.ch 30 May '13

30 May '13

1 0

Re: [Wikitech-l] ZERO architecture
by Adam Baso 30 May '13

30 May '13

Yuri, carrying the IRC chat over to mail... "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." This will require some engineering finesse for article content, Read in Another Language, and language dropdown list links. Anything's achievable, just gotta be careful. "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." Dan should probably weigh in on that piece, in case there are contractual obligations or bandwidth considerations.

1 0

GSoC / OPW community bonding period
by Quim Gil 30 May '13

30 May '13

Hi, Here's a first official task for mentors: please make sure your students don't miss this email. https://www.mediawiki.org/wiki/Summer_of_Code_2013 and https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_6#Round_6 reflect now the official list of students and mentors (primary and co-mentor). Please check that the data is correct and all linked to the appropriate user profiles. Anybody interested in any of these projects is encouraged to get CCed in the corresponding bug reports. There is where you won't miss any update and also where you can join the effort providing feedback and help. By default, wikitech-l will be used only for general announcements and big project milestones. Following the GSoC calendar, until June 17 we are in the community bonding period. See the details at https://www.mediawiki.org/wiki/Summer_of_Code_2013#Community_bonding_period If this sounds to you as "not really starting yet" then you are reading it wrong! There is a checklist for all participants. Some tasks have a tight deadline (June 1st) and the rest must be completed before June 17. This is also like a barometer: missing these first deadlines might be a symptom of other events to come. The gates are open. Let's go! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

4 6

Speed v. Size
by Tyler Romeo 30 May '13

30 May '13

So I ran a brief benchmark on my vagrant instance recently (nothing fancy, just 50,000 iterations of a single line of code), and I found that htmlspecialchars() performs *significantly* faster than strtr() (a difference of like 37%). Html::element (and other places in the Html class) prefer using strtr() with a manual list of some elements rather than htmlspecialchars(). The reasoning behind this (I think) is do make the output document slightly smaller by a few bytes by not escaping unnecessary items. So my question is if the byte reduction is really worth it, or if we would rather have a 37% reduction in escaping speed? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

5 12

Re: [Wikitech-l] Wikitech-l Digest, Vol 118, Issue 100
by anton.bolfing＠access-for-all.ch 30 May '13

30 May '13

1 0

Re: [Wikitech-l] showing videos and images in modal viewers within articles
by billinghurst 30 May '13

30 May '13

> (On a side note, the TMH behavior should be improved to actually play the video > immediately, not require a second click to play in modal view.) Please NO, if there has to be anything please make it an preference that users can toggle, but have the default as OFF. There is more than Wikipedia here; there are some of us who don't want to be playing videos that others have selected for us. Regards, Billinghurst

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l May 2013