Re: [Wikitech-l] WMF Engineering Roadmap update - 2013-07-26
Thanks Chris, I've added a link. However, the new page only links some technical design documents from which I don't get simple answers to questions such as will it be read-only? ([[OAuth]] proposed it to be so). Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gwtoolset : architecture design help
On Wed, Jul 24, 2013 at 9:12 PM, Ori Livneh o...@wikimedia.org wrote: thanks for the reply Ori. On Wed, Jul 24, 2013 at 11:59 AM, dan entous dan.entous.wikime...@gmail.com wrote: context --- i’m working on a mediawiki extension, http://www.mediawiki.org/wiki/Extension:GWToolset, which has as one of its goals, the ability to upload media files to a wiki. the extension, among other tasks, will process an XML file that has a list of urls to media files and upload those media files to the wiki along with metadata contained within the XML file. our ideal goal is to have this extension run on http://commons.wikimedia.org/ onhttp://commons.wikimedia.org/. Check out the 'DataPages' subdirectory in the mediawiki/extensions/examples repository ( https://git.wikimedia.org/summary/mediawiki%2Fextensions%2Fexamples.git). It was designed to showcase how to work with ContentHandler, and it does so by implementing an XML content type and namespace. in our last meeting with the foundation, in july, we were asked to move away from ContentHandler since there is a potential for XML files to exceed a 1mb limit. at the moment, the extension is using ContentHandler and DOMDocument to read the XML Content because in june we were asked to use ContentHandler; we originally planned to read the XML as a file and use XMLReader, which would be more efficient. in a subsequent reply to this thread, Brian offers a potential way of dealing with this issue. i’ll be able to take a look at his approach later this month, but if anyone can prove the concept beforehand or refer me to some code that has already done so, that would be great. we initially developed the extension to store the files in the File: namespace, but we were told by the Foundation that we should use ContentHandler instead. unfortunately there is an issue with storing content 1mb in the db so we need to find another solution. That's a lot of XML! You can gzip page content, FWIW. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gwtoolset : architecture design help
On Wed, Jul 24, 2013 at 9:45 PM, Mark Holmquist mtrac...@member.fsf.org wrote: thanks for the reply Mark. On Wed, Jul 24, 2013 at 08:59:25PM +0200, dan entous wrote: Mapping --- a mapping is a json that maps a metadata set to a mediawiki template. we’re currently storing those as Content in the namespace GWToolset. an entry might be in GWToolset:Metadata_Mappings/Dan-nl/Rijkmuseum. 1. does that namespace make sense? a. if not, what namespace would you recommend? I'd say that the example you gave should give a better hint about what the namespace should be called: Metadata mapping. /wiki/Metadata_mapping:Rijkmuseum makes a lot more sense from a resource/ subresource perspective, since Metadata mappings wouldn't be a resource on its own, just a parent directory for other resources. And per-user directories probably wouldn't make much sense, IMO. the mappings will serve a specific purpose. they will map potentially unique XML metadata formats and standard XML metadata formats to mediawiki template parameters. would the namespace Metadata_mappings, i prefer plural because there will be many mappings, be too generic or would that suffice for everyone? i still believe that the use of the user name is important. two or more people could come up with their own version of how to map Rijksmuseum metadata with mediawiki template parameters, so if we continue with this namespacing concept the potential title would be : Metadata_mappings:Dan-nl/Rijksmusem. one thing i forgot to mention was the addition of an extension to the title to help identify the format of the content of the title. we were planning to use .json, so the end title would be : Metadata_mappings:Dan-nl/Rijksmusem.json. would that make sense to everyone? mediawiki template parameters - the application needs to know what mediawiki template parameters exist and are available to use for mapping media file metadata to the mediawiki templates. for the moment we are hard-coding these parameters in a db table and sometimes in the code. this is not ideal. i have briefly seen TemplateData, but haven’t had enough time to see if it would address our needs. 1. is there a way to programatically discover the available parameters for a mediawiki template? TemplateData is, in fact, exactly what you need for that. i took a look at the current implementation of TemplateData on commons and have not seen it used for the templates we're currently looking at. for now i will look into coding the use of the TemplateData if present and if not, fallback to our current db look-up implementation. http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Artwork http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Book http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Musical%20work http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Photograph http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Specimen -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtrac...@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gwtoolset : architecture design help
On Wed, Jul 31, 2013 at 7:19 PM, Brian Wolff bawo...@gmail.com wrote: Metadata Set Repo - one of the goals of the project is to store Metadata Sets, such as XML under some type of version control. those Metadata Sets need to be accessible so that the extension can grab the content from it and process it. processing involves iterating over the entire Metadata Set and creating Jobs for the Job Queue which will upload each individual media file and metadata into a media file page using a Mediawiki template format, such as Artwork. some initial requirements • File sizes • can range from a few kilobytes to several megabytes. • max file-size is 100mb. • XML Schema - not required. • XML DTD - not required. • When metadata is in XML format, each record must consist of a single parent with many child • XML attribute lang= is the only one currently used and without user interaction • There is no need to display the Metadata sets in the wiki. • There is no need to edit the Metadata sets in the wiki. we initially developed the extension to store the files in the File: namespace, but we were told by the Foundation that we should use ContentHandler instead. unfortunately there is an issue with storing content 1mb in the db so we need to find another solution. 1. any suggestions? What I would suggest is a hybrid approach. The metadata file gets uploaded, and is stored using FileBackend class. (There's a couple extensions that store files without them being a file page. For example the Score extension stores the rendered files on the server, but its not attached to any file page). Once the xml file is on the server, use ContentHandler to make a new content type that stores a reference to the file [instead of the original file] (probably in the form of a mediawiki virtual file url). --bawolff thanks for the response brian. i’ll be able to take a look at this at the end of the month. if you or anyone else has the time to prototype this, prove the concept and refer me to the code that would be great. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] VE: why editing a paragraph opens the whole page?
hi, in visual editor, would it be possible to edit only a paragraph, when one clicks the edit link on a paragraph? if not, why not? currently an a decent laptop, clicking the edit link on whatever page or section takes at least 4 seconds. this is unexpectedly slow. i tried to create a bug to discuss splitting VE up to only edit parts of a page, see below. andre klapper suggested this ideally is broken up into requirements easier to implement, and i should post this to wikitext-l. as i did not see any discussion going on there about VE i tried here. please forward if this to the appropriate channel if i did not get it right again. rupert -- Forwarded message -- From: bugzilla-dae...@wikimedia.org Date: Fri, Aug 2, 2013 at 11:03 AM Subject: [Bug 52380] split up VE into components, clickable via links where it is applicable To: rupert.thur...@gmail.com Andre Klapper aklap...@wikimedia.org changed bug 52380https://bugzilla.wikimedia.org/show_bug.cgi?id=52380 WhatRemovedAddedStatusREOPENEDRESOLVED Resolution---WONTFIX *Comment # 5 https://bugzilla.wikimedia.org/show_bug.cgi?id=52380#c5 on bug 52380 https://bugzilla.wikimedia.org/show_bug.cgi?id=52380 from Andre Klapper aklap...@wikimedia.org* Please discuss such huge design decision suggestions first with developers on a mailing list, like http://lists.wikimedia.org/pipermail/wikitext-l/ , to break them down into manageable subtasks. Even if this was a valid request, it's pretty unhandable to define when this good be fixed. I mark your proposed solution again as WONTFIX, as bug reports should be about problems instead. Please leave it like that as the solution proposed here is not planned to be implemented by developers like that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [GSoC] IMPORTANT: Mentor Midterm Evaluations 29 July - 2 August
All the mentor evaluations and student evaluations are in for our twenty GSoC projects, comfortably ahead of the deadline. Thanks for preventing potential stress-induced ulcers. :-) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VE: why editing a paragraph opens the whole page?
On 2 August 2013 12:43, rupert THURNER rupert.thur...@gmail.com wrote: i tried to create a bug to discuss splitting VE up to only edit parts of a page, see below. andre klapper suggested this ideally is broken up into requirements easier to implement, and i should post this to wikitext-l. as i did not see any discussion going on there about VE i tried here. please forward if this to the appropriate channel if i did not get it right again. wikitext-l has had literally no posts since early June. It's certainly not where VE discussion is going on. Why would someone asking about VE be directed there? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VE: why editing a paragraph opens the whole page?
On 08/02/2013 07:49 AM, David Gerard wrote: On 2 August 2013 12:43, rupert THURNER rupert.thur...@gmail.com wrote: i tried to create a bug to discuss splitting VE up to only edit parts of a page, see below. andre klapper suggested this ideally is broken up into requirements easier to implement, and i should post this to wikitext-l. as i did not see any discussion going on there about VE i tried here. please forward if this to the appropriate channel if i did not get it right again. wikitext-l has had literally no posts since early June. It's certainly not where VE discussion is going on. Why would someone asking about VE be directed there? Wikitext-l used to be where we talked about Parsoid *and* VE. Now that discussion of VE has moved to wikitech-l I've altered the list description at https://lists.wikimedia.org/mailman/listinfo/wikitext-l accordingly; I reckon wikitext-l is now just for parser/wikitext discussion. Sorry for the confusion. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gwtoolset : architecture design help
On Fri, Aug 02, 2013 at 11:57:36AM +0200, dan entous wrote: the mappings will serve a specific purpose. they will map potentially unique XML metadata formats and standard XML metadata formats to mediawiki template parameters. would the namespace Metadata_mappings, i prefer plural because there will be many mappings, be too generic or would that suffice for everyone? There are many articles. We use Article:. There are many users. We use User:. It makes little sense to depart from established practice. i still believe that the use of the user name is important. two or more people could come up with their own version of how to map Rijksmuseum metadata with mediawiki template parameters, so if we continue with this namespacing concept the potential title would be : Metadata_mappings:Dan-nl/Rijksmusem. But the Rijksmusem isn't a subresource of you. If anything I would suggest having a base and enabling subpages so users could add their own mappings, hopefully with more informative titles than just their usernames, like Metadata_mapping:Rijksmusem/No_publication_date or something. (admittedly I made something up but you get the idea) one thing i forgot to mention was the addition of an extension to the title to help identify the format of the content of the title. we were planning to use .json, so the end title would be : Metadata_mappings:Dan-nl/Rijksmusem.json. would that make sense to everyone? There's no need for this. Everything in this namespace would be JSON, so putting that information in the title twice would be silly. i took a look at the current implementation of TemplateData on commons and have not seen it used for the templates we're currently looking at. for now i will look into coding the use of the TemplateData if present and if not, fallback to our current db look-up implementation. http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Artwork http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Book http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Musical%20work http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Photograph http://commons.wikimedia.org/w/api.php?action=templatedatatitles=Template:Specimen It wouldn't be hard to add to these templates, and I've already done it for the Information template, so this would be a good idea to do now-or-soon. Interface with Nazmul, who is Rasel160, who's been working on auto-generating forms for Commons templates in UploadWizard, and see if you can't work together on this :) Ta, -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtrac...@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Long term strategy for math on wikipedia
On 7/22/13 2:53 AM, Peter Krautzberger wrote: 2) TeX/LaTeX compatibility might be lost. Native content (e.g. maction or even subexpression links) has no counterpart in TeX. Conservative extensions of TeX can easily enable this kind of content but backward compatibility will be lost. If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry: 1. From the perspective of being able to repurpose Wikipedia articles outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind. 2. From a wikitext-readability perspective, TeX-format equations are the de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?). -Mark ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Long term strategy for math on wikipedia
On Friday 02 August 2013 09:06 PM, Delirium wrote: On 7/22/13 2:53 AM, Peter Krautzberger wrote: 2) TeX/LaTeX compatibility might be lost. Native content (e.g. maction or even subexpression links) has no counterpart in TeX. Conservative extensions of TeX can easily enable this kind of content but backward compatibility will be lost. If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry: 1. From the perspective of being able to repurpose Wikipedia articles outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind. 2. From a wikitext-readability perspective, TeX-format equations are the de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?). -Mark What??!!?? sorry I didn't get a thing from this. :-) Current scenario is: In our current Math extension, textvc is simply unable to generate equations in png except Latin languages. Also Mathjax is heavily client dependent (Unsupportably dependent) and has its own serious bugs. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Long term strategy for math on wikipedia
On 8/2/13 7:07 PM, praveenp wrote: On Friday 02 August 2013 09:06 PM, Delirium wrote: On 7/22/13 2:53 AM, Peter Krautzberger wrote: 2) TeX/LaTeX compatibility might be lost. Native content (e.g. maction or even subexpression links) has no counterpart in TeX. Conservative extensions of TeX can easily enable this kind of content but backward compatibility will be lost. If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry: 1. From the perspective of being able to repurpose Wikipedia articles outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind. 2. From a wikitext-readability perspective, TeX-format equations are the de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?). What??!!?? sorry I didn't get a thing from this. :-) Current scenario is: In our current Math extension, textvc is simply unable to generate equations in png except Latin languages. Also Mathjax is heavily client dependent (Unsupportably dependent) and has its own serious bugs. I read Peter's point 2 as discussing the possible native use of MathML tags, i.e. permitting people to write MathML into articles, rather than only using MathML as an alternate rendering path for texvc/MathJax/etc. If MathML is a render-only target, then TeX/LaTeX compatibility might be lost doesn't seem like it could be an issue. So unless I'm totally misreading, I took the discussion to be about allowing MathML in articles, which could break TeX compatibility since not all MathML tags can be rendered back into TeX equivalents. The two points above are my two concerns w.r.t. that suggestion. Am I misreading the suggestion entirely? -Mark ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Deployment highlights - week of August 5th
Hello and welcome to the shortest weekly deployment highlights email thus far. Full calendar: https://wikitech.wikimedia.org/wiki/Deployments Next week: NOTHING. Why? Wikimania. Due to decreased availability we will be postponing deployments of all software until the week after Wikimania (exempting high-need security or related fixes, of course). To be explicit: The version of MediaWiki on WMF servers is currently 1.22wmf12 everywhere (all project sites). 1.22wmf13 will rollout to the test wikis starting Thursday August 15th. As always, let me know if you have any questions, Greg PS: There are some noteworthy deploys planned for the rest of the month of August noted in the Near Term section of the Deployments page. -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Long term strategy for math on wikipedia
@Mark Just to clarify. Personally, I don't think wikitext's math format should move away from a TeX-like input language. The point I was trying making was that a conservative extension would be useful if MathML becomes a desired output. It seems to me that texvc was specifically designed to prevent fully fledged TeX input, so I wonder if it wouldn't help everyone if wasn't required on the backend anymore, only that the syntax stayed backward compatible. @paveenp I don't know what you mean by unsupportably dependent. I am also not aware of serious bugs. Could you be more specific? Peter. On Fri, Aug 2, 2013 at 10:40 AM, Delirium delir...@hackish.org wrote: On 8/2/13 7:07 PM, praveenp wrote: On Friday 02 August 2013 09:06 PM, Delirium wrote: On 7/22/13 2:53 AM, Peter Krautzberger wrote: 2) TeX/LaTeX compatibility might be lost. Native content (e.g. maction or even subexpression links) has no counterpart in TeX. Conservative extensions of TeX can easily enable this kind of content but backward compatibility will be lost. If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry: 1. From the perspective of being able to repurpose Wikipedia articles outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind. 2. From a wikitext-readability perspective, TeX-format equations are the de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?). What??!!?? sorry I didn't get a thing from this. :-) Current scenario is: In our current Math extension, textvc is simply unable to generate equations in png except Latin languages. Also Mathjax is heavily client dependent (Unsupportably dependent) and has its own serious bugs. I read Peter's point 2 as discussing the possible native use of MathML tags, i.e. permitting people to write MathML into articles, rather than only using MathML as an alternate rendering path for texvc/MathJax/etc. If MathML is a render-only target, then TeX/LaTeX compatibility might be lost doesn't seem like it could be an issue. So unless I'm totally misreading, I took the discussion to be about allowing MathML in articles, which could break TeX compatibility since not all MathML tags can be rendered back into TeX equivalents. The two points above are my two concerns w.r.t. that suggestion. Am I misreading the suggestion entirely? -Mark __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VE: why editing a paragraph opens the whole page?
On 08/02/2013 07:43 AM, rupert THURNER wrote: hi, in visual editor, would it be possible to edit only a paragraph, when one clicks the edit link on a paragraph? if not, why not? currently an a decent laptop, clicking the edit link on whatever page or section takes at least 4 seconds. this is unexpectedly slow. Section editing is bug https://bugzilla.wikimedia.org/show_bug.cgi?id=48429 . My understanding is that it's on their road map, but down the road. I'm not sure, but I think they are also considering implementing separate category editors, etc. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Antoine Musso hashar+...@free.fr wrote: (ensuring the NSA never gets your private keys) Which they might already have =) Or they might get anytime. If I understand it correctly, the NSA didn't steal the root passwords for Google, Facebook and the like, but properly served subpoenas. They could do (or have done) the same for the WMF, provided that the legal requirements are fulfilled. Enabling SSL for *this* use case is like stocking up ammo for the visit of the tax collector; it doesn't make you tax- exempt, it just means the collection might be a tad more complicated. Emphasis should be put on that the benefits of HTTPS every- where are primarily against *illegal* snooping. Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
