Wikitech-l December 2013

wikitech-l@lists.wikimedia.org

125 participants
115 discussions

ogv.js - JavaScript video decoding proof of concept
by Brion Vibber 06 Mar '14

06 Mar '14

TL;DR SUMMARY: check out this short, silent, black & white video: https://brionv.com/misc/ogv.js/demo/ -- anybody interested in a side project on in-browser audio/video decoding fallback? One of my pet peeves is that we don't have audio/video playback on many systems, including default Windows and Mac desktops and non-Android mobile devices, which don't ship with Theora or WebM video decoding. The technically simplest way to handle this is to transcode videos into H.264 (.mp4 files) which is well supported by the troublesome browsers. Unfortunately there are concerns about the patent licensing, which has held us up from deploying any H.264 output options though all the software is ready to go... While I still hope we'll get that resolved eventually, there is an alternative -- client-side software decoding. We have used the 'Cortado <http://www.theora.org/cortado/>' Java applet to do fallback software decoding in the browser for a few years, but Java applets are aggressively being deprecated on today's web: * no Java applets at all on major mobile browsers * Java usually requires a manual install on desktop * Java applets disabled by default for security on major desktop browsers Luckily, JavaScript engines have gotten *really fast* in the last few years, and performance is getting well in line with what Java applets can do. As an experiment, I've built Xiph's ogg, vorbis, and theora C libraries cross-compiled to JavaScript using emscripten<https://github.com/kripken/emscripten>and written a wrapper that decodes Theora video from an .ogv stream and draws the frames into a <canvas> element: * demo: https://brionv.com/misc/ogv.js/demo/ * code: https://github.com/brion/ogv.js * blog & some details: https://brionv.com/log/2013/10/06/ogv-js-proof-of-concept/ It's just a proof of concept -- the colorspace conversion is incomplete so it's grayscale, there's no audio or proper framerate sync, and it doesn't really stream data properly. But I'm pleased it works so far! (Currently it breaks in IE, but I think I can fix that at least for 10/11, possibly for 9. Probably not for 6/7/8.) Performance on iOS devices isn't great, but is better with lower resolution files :) On desktop it's screaming fast for moderate resolutions, and could probably supplement or replace Cortado with further development. Is anyone interested in helping out or picking up the project to move it towards proper playback? If not, it'll be one of my weekend "fun" projects I occasionally tinker with off the clock. :) -- brion

4 5

Re: [Wikitech-l] [WikimediaMobile] Wikimedia Commons mobile photo uploader app updated on iOS and Android
by rupert THURNER 05 Mar '14

05 Mar '14

On Sun, Aug 25, 2013 at 7:46 PM, Yuvi Panda <yuvipanda(a)gmail.com> wrote: > Hey rupert! > > On Sun, Aug 25, 2013 at 10:21 PM, rupert THURNER > <rupert.thurner(a)gmail.com> wrote: >> hi brion, >> >> thank you so much for that! where is the source code? i tried to >> search for "commons" on https://git.wikimedia.org/. i wanted to look > > Android: https://git.wikimedia.org/summary/apps%2Fandroid%2Fcommons.git > iOS: github.com/wikimedia/Commons-iOS > >> if there is really no account creation at the login screen or it is >> just my phone which does not display one, and which URL the aplication > > Mediawiki doesn't have API support for creating accounts, and hence > the apps don't have create account support yet. created https://bugzilla.wikimedia.org/show_bug.cgi?id=53328, maybe you could detail a little bit more how this api should look like? rupert.

4 8

RFC on PHP profiling
by Chad 18 Feb '14

18 Feb '14

I'm starting a new RFC to discuss ways we can improve our PHP profiling. https://www.mediawiki.org/wiki/Requests_for_comment/Better_PHP_profiling Please feel free to help expand and/or comment on the talk page if you've got ideas :) -Chad

5 5

IRC meeting for RFC review
by Tim Starling 05 Feb '14

05 Feb '14

I would like to have an open IRC meeting for RFC review, on Tuesday 24 September at 22:00 UTC (S.F. 3pm). We will work through a few old, neglected RFCs, and maybe consider a few new ones, depending on the interests of those present. The IRC channel will be #mediawiki-rfc. -- Tim Starling

11 16

Welcome to Ken Snider, Wikimedia Operations
by Erik Moeller 28 Jan '14

28 Jan '14

Hello all, I’m delighted to announce that Ken Snider is joining the Wikimedia operations team. He will start as an international contractor working remotely from Toronto, Canada on June 10, and will be visiting SF in the week of June 17. We’re currently in the process of seeking work authorization in the United States in the Director of TechOps position. CT has graciously agreed to support the ops leadership transition full-time through June, and part-time through July. We’ll be starting the handover while Ken is working remotely. A bit more about Ken: Ken was apparently genetically predisposed to become a sysadmin since he joined one of Canada’s first large ISPs, Primus, straight out of school in 1997 and helped build their infrastructure til 2001. He then joined a startup called OpenCOLA in 2001 which was co-founded by Cory Doctorow and developed early P2P precursors to tools like BitTorrent and Steam. It’s best known today for the development of an open source (GPL’d) cola recipe which is still in use (more than 150,000 cans sold if Wikipedia is to be believed). Ken got involved in one of Cory’s pet projects, BoingBoing.net which some of you may have heard of ;-), and has been their sysadmin since 2003. After a stint from 2001-2005 at DataWire, Ken became Director of Tech Ops at Federated Media, a role he held from 2005-2012. Federated Media is an ad network that was founded to support high traffic blogs and sites that want to stay independent of large publishers, with a network that supports more than 1B requests/day. One of the unusual challenges at FM was that the company grew through acquisitions of various blogging and publishing networks. This led to the challenge of integrating very heterogeneous operations and engineering infrastructure, including multiple geographically distributed ops teams and data-center locations. As DTO, Ken led these efforts, such as OS standardization, development of a unified deployment infrastructure, etc. Ken also ensured that the operations group partnered effectively with the various engineering teams developing site features and enhancements. I want to again take this opportunity to thank CT Woo for his tireless operations leadership since December 2010. I’d also like to thank everyone who’s participated in the Director of TechOps search process. Please join me in welcoming Ken to the Wikimedia Foundation and the community. :-) All best, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

4 4

!ask
by Ori Livneh 24 Jan '14

24 Jan '14

Can we deprecate usage of '!ask' on IRC? > ori-l: !ask > wm-bot: Hi, how can we help you? Just ask your question. It's annoying when people ask to ask, but the people who do so do it out of insecurity or lack of experience, and so they're the last people we should be siccing our bots on. I've used '!ask' a lot before but I'm going to stop. I hope others do the same.

9 10

Module storage is coming
by Ori Livneh 23 Jan '14

23 Jan '14

The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will inaugurate the era of ResourceLoader module storage -- an era which will be marked by terrifying and hilarious new bugs, intermittent client-side failures, and generally inexcusable disruptions to user experience. Sounds exciting? Read on! What is it? ----------- "Module storage" refers to the use of localStorage in ResourceLoader as an auxiliary to the browser cache. ResourceLoader, remember, is the MediaWiki subsystem that delivers JavaScript and CSS to your browser. One of its primary functions is to minimize the total number of network requests that your browser needs to make in order to render the page, and to make the remaining requests as slim as possible. One of the ways ResourceLoader does this is by making a list of all the different components your browser needs and then transmitting them in bulk. The downside of this approach is that a small update to MediaWiki's code, touching perhaps one or two components, will often force the browser to throw out (and re-retrieve) a bunch of unrelated modules that did not change and did not ostensibly need to be re-retrieved. This is because the browser cache operates on the level of network requests; it is not intelligent enough to decompose a request into its constituitive parts and to cache these parts separately from one another. Starting with the 1.23wmf2 branch, ResourceLoader will check if your browser implements localStorage, a mechanism for storing structure data. If it does, ResourceLoader will use it as an auxiliary cache, capable of versioning individual components. Why? ---- The primary goals are: * Destabalize MediaWiki's front-end code, by coupling it to an inconsistently-implemented and poorly-understood HTML5 API. * Make debugging fun again, by adding another layer of caching to MediaWiki. Yes!! However, as with all new features, unintended side-effects are possible. Specific concerns for module storage include the risk of making the network footprint of page loads smaller, resulting in improved latency. But seriously, -------------- * Module storage is enabled only if the underlying browser supports localStorage (~89% of browsers in use, according to <http://caniuse.com/#feat=namevalue-storage>). Users with older browsers will not see a benefit, but they will not suffer a penalty either. * Module storage may or may not improve site performance. We need to test it against a wide range of browsers and platforms to know for certain. If it doesn't improve performance, we'll blame it on you, your poor choice of browsers, and your uncooperative attitude, but then we'll scrap it. How can I test it? ------------------ Glad you asked! Module storage is enabled by default on the beta cluster, and on test & test2 wikis. The simplest way you can help is by being alert to to performance regressions and front-end code breakage. If you know how to use your browser's JavaScript console, you can get stats about module storage usage on the current page by checking the value of 'mw.loader.store.stats'. When the code is rolled out across the cluster, it will be disabled by default, but you will be able to opt-in by manually setting a cookie in your browser. I will follow up with the exact details. If module storage proves stable enough for production use, we'll seek to asses its utility by running a controlled study of some kind. If we can demonstrate that module storage leads to a significant improvement in performance, we'll enable by it default. --- Ori Livneh ori(a)wikimedia.org

27 57

RFC cluster summary: HTML templating
by Rob Lanphier 22 Jan '14

22 Jan '14

Hi folks, This is an attempt to summarize the list of RFCs that are listed under this cluster: https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_Clusters#HTML_t… ...and possibly get a conversation going about all of this in advance of the Architecture Summit. The main focus of all of these RFCs is around HTML generation for user interface elements. This category is not about wikitext templates or anything to do with how we translate wikitext markup "Template Engine" is Chris Steipp's submission outlining the use of Twig. From my conversations with Chris, it's not so much that he's eager to adopt Twig specifically so much as standardize on *something*, and make sure there's usage guidelines around it to avoid common mistakes. He's seen many attempts at per-extension template libraries that bloat our code and often start off with big security vulnerabilities. There are many extensions that use Twig, and it seems to be a popular choice for new work, so Chris is hoping to standardize on it and put some usage standards around it. "HTML templating library" is Ryan Kaldari's submission, promoting the use of Mustache or something like it. His main motivation is to have a Javascript template library for front-end work, but is hoping we choose something that has both Javascript and PHP implementations so that any PHP template system implementation is compatible with what we use for Javascript templating. "MVC Framework" is Owen Davis's description of Wikia's Nirvana framework, which has been central to all of the user-facing work they've been doing for the past 2-3 years. As Owen points out in the talk page for this, it's really view-controller rather than full MVC. A big plus of adopting this RFC is that it would make it much more likely that Wikia-developed extensions (of which there are many) would be of greater use to the larger MediaWiki community, and would generally help facilitate greater collaboration between Wikia and the rest of us. "OutputPage Refactor" is another submission from Owen Davis, which isn't really about templating, so much as taking the HTML generation code out of OutputPage. Wikia has been maintaining a fork of OutputPage for quite some time, so they already have quite a bit of experience with the proposed changes. This is clustered with the templating proposals, since I imagine the work that gets factored out of OutputPage would need to be factored into whatever templating system we choose. The first three seem somewhat mutually exclusive, though it's clear our task is likely to come up with a fourth proposal that incorporates many requirements of those three. The OutputPage Refactor proposal, given some fleshing out, may not be controversial at all. Where should we go from here? Can we make some substantial progress on moving one or more of these RFCs over the next few weeks? Rob

15 26

Jake requests enabling access and edit access to Wikipedia via TOR
by Thomas Gries 13 Jan '14

13 Jan '14

Hi, during the 30C3 Congress [1] in Hamburg - where neither Wikipedia Foundation nor MediaWiki were formally present this year (but should be next year)- Jacob Appelbaum [2] - core member of the TOR project - complained in one of his numerous talks that the (edit) access to Wikipedia via TOR is not possible. He requested that a way should be found to enable the TOR access including edit access to Wikipedia. I am just the messenger of this message. Regards, Tom [1] https://events.ccc.de/congress/2013/wiki/ [2] https://en.wikipedia.org/wiki/Jacob_Appelbaum

21 44

npm publish
by Dan Andreescu 10 Jan '14

10 Jan '14

We needed to write an npm module for mediawiki oauth, and we're about to publish it to the npm registry. I just wanted to check whether we had a wikimedia account on https://npmjs.org/. If not, do we want one?

5 7

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 December 2013