Wikitech-l November 2013

wikitech-l@lists.wikimedia.org

128 participants
123 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 06 Mar '14

06 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

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

Google Code-in starting NOW (important!)
by Quim Gil 31 Dec '13

31 Dec '13

Hi, Google Code-in is about to start: http://www.google-melange.com/gci/homepage/google/gci2013 https://www.mediawiki.org/wiki/Google_Code-In We have currently 72 tasks published and 13 mentors. We are still looking for more mentors and tasks. If you are interested, contact me. This is the first time Wikimedia participates in this program and the only certain prediction at this point is that we all will learn a lot. We have been warned that especially the first two weeks will be quite messy, with many impatient newcomers landing in our community channels and asking for help / feedback / review. Please be kind with them. Things will eventually settle down, partially because our documentation will be better, partially because the students interested in Wikimedia will be familiar with the basics and will know where/how to ask. Ideally https://www.mediawiki.org/wiki/Google_Code-In should contain answers and links to answers for the frequently asked questions. Try to answer GCI students with links to the appropriate pages, and try to assure that such links are available at our GCI wiki page. Thank you for your patience. I have no doubt that your direct or indirect help will pay off with better documentation for all kinds of newcomers interested in many areas of contribution. /me goes to prepare a hot beverage. It is going to be fun. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

3 12

Deprecation notice for etherpad-old.wikimedia.org
by Alexandros Kosiaris 30 Dec '13

30 Dec '13

Hello, As many of you might be aware, etherpad.wikimedia.org has been migrated a couple of months ago from the old and no longer supported etherpad software to the new, actively supported, etherpad-lite software. The move also involved the migration of pads from the old software to the new, a process which was quite successful, albeit not without glitches. Since then the old installation has been kept around under http://etherpad-old.wikimedia.org in a read-only state in order to facilitate people to access pads that, for whatever reason, may not have made it to the new installation unscathed (or at all). This service will be discontinued and taken offline on Monday, 30 December 2013. That grants 30+ days to people to copy out any necessary pads. With that in mind, the operations team would like to remind everyone that etherpad.wikimedia.org was never intended to be a permanent storage for pads. Preservation of a pad is up to the people interested in preserving that pad in another format. Regards, -- Alexandros Kosiaris <akosiaris(a)wikimedia.org>

1 1

Wikipedia mobile app rewrite early test builds available
by Brion Vibber 18 Dec '13

18 Dec '13

As folks may be aware, over in the Wikimedia Mobile Apps team we're starting a refresh of the Wikipedia mobile apps for Android and iOS, which have not been updated in a while and are now wayyy behind the mobile web in features and UI awesomeness. The new apps are using native UI around the content web view, which lets us integrate with the system better than the old PhoneGap-based HTML app, and provide long-desired features like pinch-to-zoom in the article view. Our first 2-week work sprint is finishing up, and builds of current state are available: * Android: http://dumps.wikimedia.org/android/apps-android-wikipedia-dev-sprint1.apk * iOS: on testflightapp.com (email notifications sent to our recently trimmed beta list) Both versions are pretty bare-bones, so don't be surprised by missing icons, toolbar buttons that don't work, or incomplete design. :) This first feature sprint concentrated on getting search & basic content loading working. You can type into the search box, the search results include thumbnails, and you can select a search result to load the article. You can also click on internal links in both iOS and Android versions, though they get a little flaky from there out. :) Back/forward is not yet implemented on iOS; back works on Android but there's no forward. Note also the pretty animation when following links on Android -- neat! Next sprint's release should look more polished, as we'll have some more navigation working, and the first sprint stuff prettied up to better match design: https://upload.wikimedia.org/wikipedia/commons/c/c8/Search-overlay-01.png For in-progress design & UX ideas for the new app, see https://www.mediawiki.org/wiki/Wikipedia_App_Design Note that you may or may not need to manually uninstall the old app if it's present first. If you want to try the iOS version and aren't on the beta list you'll have to build it yourself on a Mac with XCode 5, and then you can only install it on your device if you are a registered iOS developer (thank Apple's restrictions on third-party app installations!): $ git clone https://gerrit.wikimedia.org/r/apps/ios/wikipediaapps-ios-wikipedia (Unfortunately we cannot add new people to the iOS beta list until Apple clears out old entries from our 100-max device database, either at the end of the calendar year or in February when our membership rolls over. Yeah, I'm serious...) And of course you can build the Android version too, and run it with no restrictions: $ git clone https://gerrit.wikimedia.org/r/apps/android/wikipediaapps-android-wikipedia Note that there's separate work going to revitalize the Wikipedia app for Firefox OS, which will remain HTML5-based as that's how native Firefox apps work! That's being spearheaded by the Wikimedia Mobile Partnerships & Wikipedia Zero team. -- brion

5 6

Architecture Summit -- Gathering all relevant RfC's
by Diederik van Liere 11 Dec '13

11 Dec '13

Heya, The Architecture Summit will be upon us in less than two months. To make sure that this Summit is going to be productive it is important that we discuss the right RfC's. Before deciding which RfC's should be discussed at the Summit I want to make sure that https://www.mediawiki.org/wiki/Requests_for_comment contains all RfC's and that all important topics have an RfC. If you have a Mediawiki related RfC in a personal notepad, on your User Page, in your mind then this would be a great moment to write or move it under https://www.mediawiki.org/wiki/Requests_for_comment and add an entry to the table. If you don't have 'move' rights then please let me know and I can move it for you. If you know of a topic that *should* have an RfC but does not yet have an RfC then please reply to this list mentioning the topic. I will check with Tim/Brion to see how these topics can get an RfC. Once we have collected all relevant RfC's under https://www.mediawiki.org/wiki/Requests_for_comment then I will make a page where everybody can express their interest in which RfC's should be discussed at the Summit. Questions? Let me know! Best, Diederik

4 4

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