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
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.
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/]
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?
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
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.
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
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
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
> (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