Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
152 discussions

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

07 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 06 Feb '14

06 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 29 Jan '14

29 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 25 Jan '14

25 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

Call for participation: Wikis devroom at FOSDEM
by Quim Gil 03 Dec '13

03 Dec '13

Spread the news! https://lists.fosdem.org/pipermail/wikis-devroom/2013-October/000000.html Wikis devroom - FOSDEM, Brussels, 1 & 2 February 2014 CALL FOR PARTICIPATION IN SHORT We accept proposals for wiki related submissions. The formats accepted are 25min sessions or 5min lighting sessions. All proposals must be submitted via https://penta.fosdem.org/submission/ Deadline: 30 November 2013 Questions? Feedback? Willing to help? https://lists.fosdem.org/listinfo/wikis-devroom BACKGROUND Wikis are essential tools for online collaboration, open knowledge and free software. They are everywhere: from the mainstream Wikipedia to a myriad of public, academic and corporate knowledge bases and personal sites. And most of them are open source software. Wikis became popular thanks to the edit button allowing users to create and modify text-based web pages easily. Over the years wikis have become more powerful, handling more content types, allowing better look & feel, championing localization and integrating (sometimes) with other tools. The development continues, with hundreds of professional and volunteer contributors specializing in this area. There are also challenges: the competition from (mainly proprietary and corporate) social media and online office tools, keeping up with UX expectations from users, editors and sysadmins, compatibility across different wiki engines and other publishing tools, collaboration between wiki projects... SCOPE Wikis devroom is a place to showcase and discuss * new features, especially exploring areas beyond plain text editing * compatibility and integration with other tools and services * lessons learned from deployments, surveys, research... * cross-project collaboration We want to focus on sessions for a technical audience including savvy editors. Basic introductions for end users and long tutorials are out of scope. FORMAT One day, one room. Most of the schedule will be filled with sessions of about 25 minutes that have gone through a call for participation. We will have a WikiWiki Hour of lightning presentations (5 minutes each). We will organize a panel session with representation of key wiki projects - the specific topic to be decided as we confirm the participants. ORGANIZATION Quim Gil (MediaWiki), Vincent Massol (XWiki) and Jean-Marc Libs (Tiki).

3 4

Bugzilla Weekly Report
by reporter 15 Nov '13

15 Nov '13

8 11

jQuery UI may not be loaded by default on your wiki
by Matthew Flaschen 14 Nov '13

14 Nov '13

We have merged a couple changes so that jQuery UI is not loaded by code that doesn't need it. See https://bugzilla.wikimedia.org/show_bug.cgi?id=55550 for details. That means gadgets and user scripts that use jQuery UI should explicitly load the appropriate module. https://www.mediawiki.org/wiki/Extension:Gadgets has info on adding gadget dependencies. User scripts can use mw.loader.using (https://www.mediawiki.org/wiki/RL/DM#mw.loader.using). A list of jquery.ui modules is at https://www.mediawiki.org/wiki/RL/DM#jQuery_UI . There is one remaining issue that may affect a few wikis. If your wiki uses jquery.ui buttons in wikitext, the styles will not be loaded unless something explicitly loads or depends on jquery.ui. If you notice styles missing from your wiki, you can add: // Load jquery.ui.button so button styles work in wikitext mw.loader.using( 'jquery.ui.button' ); to the site Common.js Don't do this unless it's actually needed, since this does have a performance impact (although it is not loading all of jquery.ui). If you do add it, please include the comment so people know why it's being loaded. This will roll out to the test wikis, plus MW.org, 2013-10-31, the remaining non-Wikipedia wikis the 4th, and the Wikipedias, the 7th. Matt Flaschen

1 1

migrating hooks doc to doxygen?
by Antoine Musso 13 Nov '13

13 Nov '13

Hello, Since we introduced hooks in MediaWiki, the documentation has been maintained in a flat file /docs/hooks.txt . Over the week-end I have converted the content of that file to let Doxygen recognize it. The patchset is: https://gerrit.wikimedia.org/r/#/c/66128/ I have used that patch to generate a temporary documentation. That lets everyone browse the result easily. The produced result is: A landing page: https://doc.wikimedia.org/mw-hooks/hooks_mainpage.html The doc overview: https://doc.wikimedia.org/mw-hooks/page_hooks_documentation.html A list of hooks with their documentation: https://doc.wikimedia.org/mw-hooks/page_hooks_list.html I think that makes it a bit more accessible to everyone and Doxygen autolink to referenced classes. Some issues I have: - the hooks are listed alphabetically when they could be regrouped by theme (like API, SpecialPages, HTML Forms ...). - The hooks are documented in a separate file (still docs/hooks.txt), when we might want to have the doc near the wfRunHooks() call. Thoughts ? -- Antoine "hashar" Musso

13 17

$wgRedactedFunctionArguments
by Ori Livneh 13 Nov '13

13 Nov '13

The 1.22 release adds a new configuration variable, $wgRedactedFunctionArguments, that allows administrators of MediaWiki installations to designate function arguments that should be redacted from stack traces. For example: $wgRedactedFunctionArguments[] = array('User::comparePasswords' => array( 0, 1 ) ) This value specifies that whenever the method User::comparePasswords appears in an exception stack trace, the value of the first and second arguments are to be redacted, meaning the string 'REDACTED' is inserted where the argument value would otherwise appear. The case for this feature was made in <https://bugzilla.wikimedia.org/show_bug.cgi?id=30714>. I think that it is a design blunder, and that we should remove it from MediaWiki. The task of making $wgRedactedFunctionArguments comprehensive is hopelessly gargantuan. It would require something like a full trace of the flow of data throughout all of MediaWiki and its extensions. The best case scenario is that the feature is not used. The worst case -- which seems to be materializing, judging by the default value assigned to it in DefaultSettings.php -- is that it is used with a short and chronically out-of-date list of obvious suspects, and that the resultant traces leak private data. This is actually worse than making no attempt at all to sanitize traces, because it is liable to mislead and inspire false feelings of confidence. I think that the proper way to handle low-level operational data like stack traces is to make it clear that it is liable to contain sensitive information, and to make no pretense at all of sanitizing it. If there is a credible need for outputting redacted traces, the output should exclude *all* values, not just the ones that someone remembered to configure. --- "Base access decisions on permission rather than exclusion. This principle...means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation." ("The Protection of Information in Computer Systems", http://web.mit.edu/Saltzer/www/publications/protection/Basic.html) --- Ori Livneh ori(a)wikimedia.org

8 8

Jump to page:

2026

2025

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