On 09/19/2013 10:04 AM, Jon Robson wrote:
Thanks Tim for running those data. That seems to suggest the URL
structure works for the most case.
It certainly confirms that search engines link to working links, and
users typing URLs manually are rare and (eventually) learn to prefix
/wiki/. I am
On 10/01/2013 07:27 AM, Mark A. Hershberger wrote:
On 10/01/2013 09:25 AM, Brion Vibber wrote:
We've been moving away from being friendly to old-style shared-hosting
servers for some time with key features that people are going to expect to
replicate on their MediaWikis in the future...
On 10/01/2013 09:46 AM, Christopher Wilson wrote:
I'm usually just an observer on these lists, but I'll weigh in as a user
who runs MediaWiki on a shared host. The host *is* a VPS, but our wiki is
used by the environmental department of a large international non-profit.
As such it lives on the
On 10/01/2013 02:51 PM, David Gerard wrote:
On 1 October 2013 22:34, C. Scott Ananian canan...@wikimedia.org wrote:
I know you're trolling, but: presumably wikimedia would start by
maintaining their own apt repository.
http://apt.wikimedia.org/
A mediawiki.org PPA is an idea that sounds
On 10/02/2013 06:42 AM, Mark A. Hershberger wrote:
But now we have REAL data on the sorts of hosting people use to run
their wikis.
Yesterday, I went to Jamie of WikiApiary and talked to him about ways to
get this sort of data from his bot. The first idea I had was the
reverse DNS for the
On 10/10/2013 01:31 AM, JFC Morfin wrote:
Thank you for your response. I certainly understand this. My question is
in your almost. My interest is in a seemless
transition/simulteaneousity between the current user/admin experience
and a NoSQL approach. This is why I am interested in knowing if
On 10/21/2013 08:45 PM, Chris Steipp wrote:
Hi all,
I wanted to get some input from you all about any ideas or plans they have
for identifying OAuth user in your applications.
tl;dr, Since lots of people want to do authentication with OAuth, I'm
thinking we'll implement a custom way to get
On 11/04/2013 12:58 PM, Erik Moeller wrote:
This was due to a broken deployment of Parsoid, the new MediaWiki
parser used by VisualEditor. A new library dependency defaulted to
iso8859-1 instead of utf-8, which caused character munging to occur.
I have created a post-mortem at
On 11/13/2013 08:10 AM, Tyler Romeo wrote:
On Wed, Nov 13, 2013 at 12:45 AM, Erik Moeller e...@wikimedia.org wrote:
Most likely, we'll end up using Parsoid's HTML5 output, transform it
to add required bits like licensing info and prettify it, and then
render it to PDF via phantomjs, but
On 11/10/2013 10:51 PM, Tim Starling wrote:
On 08/11/13 03:40, C. Scott Ananian wrote:
Certain people 'own' larger collections of modules -- like there are
subsystem owners in the linux kernel dev world.
My concern with this kind of maintainer model is that RFC review would
tend to be
On 11/13/2013 08:18 PM, MZMcBride wrote:
Matthew replied on-wiki, but I'll add that there's a dream within the
MediaWiki tech community to be able to simply do apt-get mediawiki or
similar on a spun-up virtual machine and everything will quickly and
easily be set up for you.
There's a
On 11/17/2013 03:41 AM, Nathan Larson wrote:
Following the mediawiki-l
discussionhttp://lists.wikimedia.org/pipermail/mediawiki-l/2013-November/042038.htmlabout
$wgNoFollowLinks and various other discussions, in which some
discontent was expressed with the current two options of either
On 11/18/2013 09:46 AM, Nathan Larson wrote:
I do think the implications of changing how nofollow is applied are very
different on, say, Wikipedia than they would be on a small or even
medium-sized wiki
As I said, at least for Google there should be no difference as it
ignores rel=nofollow on
On 11/18/2013 10:11 AM, Nathan Larson wrote:
Do we have any way of knowing that Yong-Gang Wang of Google is correct
about this? I sent a message to this
individualhttps://plus.google.com/105349418663822362024/about(hopefully
it's the same guy) asking for more information. It seems like a
On 11/18/2013 12:27 PM, Risker wrote:
To be honest, I suspect if the Google fellow said anything like this, it
was that they might ignore nofollow on Wikimedia wikis, but I'm pretty
certain that he didn't say Mediawiki wikis.
I remember being surprised too that it applied to all MediaWiki
On 11/18/2013 01:59 PM, Gabriel Wicke wrote:
On 11/18/2013 12:27 PM, Risker wrote:
To be honest, I suspect if the Google fellow said anything like this, it
was that they might ignore nofollow on Wikimedia wikis, but I'm pretty
certain that he didn't say Mediawiki wikis.
I remember being
On 12/08/2013 11:55 PM, Tyler Romeo wrote:
I'm sure this has already been taken into consideration, but keep in mind
that code that is executed using eval() in Javascript is *not* optimized by
the V8 compiler like normal script resources are.
Are you sure this is still the case?
On 12/09/2013 08:33 PM, Tyler Romeo wrote:
On Mon, Dec 9, 2013 at 2:15 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Are you sure this is still the case?
https://code.google.com/p/v8/issues/detail?id=2315 seems to suggest that
this was fixed in V8 last year.
Not sure if it's related
On 01/16/2014 07:56 PM, Tim Starling wrote:
I think the interwiki map should be retired. I think broken links
should be removed from it, and no new wikis should be added.
Interwiki prefixes, local namespaces and article titles containing a
plain colon intractably conflict. Every time you add
On 01/17/2014 12:58 AM, Petr Bena wrote:
I think it would be cool if an extension was created which would allow
everyone to specify what units they prefer, and the values in articles
would be converted automatically based on preference.
Whatever you do, make it client-side. It would be great
On 01/17/2014 10:17 AM, Jay Ashworth wrote:
- Original Message -
From: Gabriel Wicke gwi...@wikimedia.org
Currently Flow is the only project using HTML storage. We are working on
preparing this for MediaWiki proper though, so in the longer term the
interwiki conflict issue should
On 01/17/2014 02:11 PM, Petr Bena wrote:
it can't be done client side. It must be done on both sides, so that
user can save their preference into database without having to set it
everytime they get their cookies wiped (which in my case is like 10
times a day just by switching devices and
On 01/21/2014 01:23 AM, Randall Farmer wrote:
Anyway, I'm saying too many fundamentally unimportant words. If the status
quo re: compression in fact causes enough pain to give histzip a fuller
look, or if there's some way to redirect the tech in it towards a useful
end, it would be great to
On 02/10/2014 04:13 PM, Arthur Richards wrote:
A few of us have been discussing how awesome it would be to use
MediaWiki-Vagrant[1] to create a portable production-like environment.
We recently started a push on this by packaging Parsoid and other
services (rt test server, mathoid, ..) as
On 02/14/2014 11:32 AM, Derric Atzrott wrote:
If I install the Visual Editor mediawiki extension on the Wiki that I manage
here at my work and also setup Parsoid, will new pages be saved with Wikitext
still?
Yes. All content is currently stored as wikitext, so you are naturally
able to use the
On 02/14/2014 12:47 PM, Derric Atzrott wrote:
If I install the Visual Editor mediawiki extension on the Wiki
that I manage here at my work and also setup Parsoid, will new
pages be saved with Wikitext still?
Yes. All content is currently stored as wikitext, so you are
naturally able to use
On 02/14/2014 04:00 AM, Toni Hermoso Pulido wrote:
Within an extension, is there a
specific method (via Parser class, for instance) or a more or less
direct way that could turn a template in a wikitext string into an
object or associative array.
If you need both the parameters (including
On February 15, 2014 12:05:49 PM PST, Daniel Kinzler dan...@brightbyte.de
wrote:
Implementing a HTML content type in mediawiki would be pretty trivial.
That way,
a page could natively contain HTML, with no need of conversion.
Anyone up to
doing it?...
We are working towards this, but actual
On 02/16/2014 01:32 AM, David Gerard wrote:
There are extensions that allow raw HTML widgets, just putting them
through unchecked. The hard part will be checking. Note that the
rawness of the somewhat-filtered HTML is a part of WordPress's not so
great security story (though they've had a lot
On 02/15/2014 09:54 PM, Ryan Kaldari wrote:
Now that I've blamed everyone except for myself, I would like to suggest
that we stop pointing fingers and get down to brass tacks.
My question for both the designers and the free font advocates is: Are
there any free fonts that are...
1. widely
/HTML_templating
and
https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_interfaces
have more information. Gabriel Wicke will be asking for some
decisions on
both. :)
Hi Gabriel,
Could you spell out on the mailing list what decisions you
On 02/24/2014 10:52 PM, Brian Wolff wrote:
Its not neccesarily
agreed that having support for magic wiki-text altering templates on the
mediawiki level is a good thing. As far as i am aware, nobody is currently
trying to make a framework for that use case on the mediawiki level (beyond
Hi Roman!
On 02/28/2014 01:24 AM, Brian Wolff wrote:
On 2/28/14, Roman Zaynetdinov romanz...@gmail.com wrote:
Help people in reading complex texts by providing inline translation for
unknown words. For me as a non-native English speaker student sometimes is
hard to read complicated texts or
Emmanuel,
On 03/01/2014 09:01 AM, Emmanuel Engelhart wrote:
Hi
For the first time, we have achieved to release a complete dump of all
encyclopedic articles of the Wikipedia in English, *with thumbnails*.
this is great news. Congratulations!
Gabriel
On 03/07/2014 10:08 AM, Greg Grossmeier wrote:
What we should do, however, is have a true deployment pipeline.
Briefly defined: A deployment pipeline is a sequence of events that
increase your confidence in the quality of any particular build/commit
point.
A typical example is:
commit -
On 03/10/2014 02:04 PM, Jon Robson wrote:
I just wondered if anyone doing MediaWiki development had any
experience in catching CSS regressions?
We don't have experience with this yet in Parsoid land, but are looking
for something very similar. We are interested in mass rendering
comparisons of
Adding wikitech and Mark / Markus. Please subscribe to
https://lists.wikimedia.org/mailman/listinfo/packaging if you are interested
in WMF packaging efforts!
On 03/18/2014 11:22 AM, Gabriel Wicke wrote:
Hi,
a while ago we agreed to set up a public Debian repository for WMF-developed
software
We made some good progress on KnockOff [1,2] recently. It is currently the
fastest library in our micro benchmarks [3] despite having a DOM-based
compiler with the associated security advantages. Matt has started work on
the PHP port before going on vacation, but I expect that we'll have a PHP
On 03/26/2014 10:55 AM, Chris Steipp wrote:
On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz nu...@wikimedia.org wrote:
Additionally, how you escape a plain parameter like class vs. an
href vs. a parameter that is inserted into a url vs. an id attribute are
all different escaping strategies.
On 03/27/2014 08:32 AM, C. Scott Ananian wrote:
Currently mediawiki constrains image size primarily by width, which doesn't
work so well for images which are taller than they are wide. There is no
way to ask for an image which has a height equal to the default thumbnail
size (without
On 03/27/2014 10:00 AM, C. Scott Ananian wrote:
But I'd also be interested in seeing a concrete counter-proposal for
semantic markup. Presumably from the Visual Editor UX perspective,
this is just a drop down labelled Style, along with (presumably)
some discouragement of manual resize. But
On 03/30/2014 02:23 AM, Nuria Ruiz wrote:
What I am saying is that the parsing and escaping scheme we need is much
simpler if you disallow the use case of passing the template engine
something that is not data.
Let me explain as this as it has to do more with correctness that with
security
On 04/01/2014 10:55 AM, Sumana Harihareswara wrote:
Gabriel, Matt - is the PHP runtime ready?
At this point it supports only a part of the TAssembly spec:
https://github.com/mattofak/knockoff
Blame other stuff getting in the way. Matt or me should find some time to
knock out (ha!) the
On 04/01/2014 03:49 PM, Rob Lanphier wrote:
I'm eager to get some closure on the overall RFC about HTML templating
myself. Am I right to assume that the process is:
1. Get Knockoff complete enough that we can fairly evaluate it against the
other proposals
2. Reopen the conversation about
On 04/02/2014 04:33 AM, Nuria Ruiz wrote:
My bigger point was to highlite that with a string concatenation engine you
can satisfy security concerns plus have a template engine that performs
really well if you respect the data and markup separation.
The runtime is string-based for performance
On 04/02/2014 11:09 AM, Sumana Harihareswara wrote:
TL;DR: who's testing out the non-Knockout approaches?
Lots of teams have used a variety of template libraries, see the RFC [1]. I
know that for example handlebars is used in a few teams right now.
Gabriel
[1]:
Hi,
we had a short meeting this morning to discuss our Debian packaging and
repository plans for WMF-developed software. The meeting notes are now
posted at
https://www.mediawiki.org/wiki/Talk:Packaging#Meeting_notes_2014-04-04
We agreed to set up a public repository at releases.wikimedia.org
On 04/03/2014 05:48 PM, Nikolas Everett wrote:
Now that TitleValue has been merged - what's next? I'll admit I'm an odd
choice to be sending out this email [1], but someone's got to do it. So,
I'm thinking, maybe:
2. Start writing code in the same fashion for an upcoming project. I
On 04/11/2014 12:06 PM, Sumana Harihareswara wrote:
So, just to clarify, this is NOT a discussion of overhauling the
outward-facing MediaWiki web API -- that's taking place in
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap .
The discussion is not about replacing the existing
On 04/24/2014 05:24 AM, Daan Kuijsten wrote:
On 23-Apr-14 21:29, wikitech-l-requ...@lists.wikimedia.org wrote:
Re: API attribute ID for querying wikipedia pages
@Matma Rex: This is way to general, I think it would be a lot better when
this would be in more detail. For example when I want
On 04/30/2014 12:51 PM, Brion Vibber wrote:
* at upload time, perform a series of scales to produce the mipmap levels
* _don't consider the upload complete_ until those are done! a web uploader
or API-using bot should probably wait until it's done before uploading the
next file, for
On 05/13/2014 05:37 PM, Daniel Kinzler wrote:
Hi all!
During the hackathon, I worked on a patch that would make it possible for
non-textual content to be included on wikitext pages using the template
syntax.
The idea is that if we have a content handler that e.g. generates awesome
On 05/07/2014 10:47 PM, Tyler Romeo wrote:
One interesting idea might be what Reddit does:
For a moderator of a subreddit, whenever they make a post it just appears
normally. However, after posting they can choose to officiate it. All
that does is highlight their username a different color
On 05/14/2014 01:40 PM, Daniel Kinzler wrote:
This means that HTML returned from the preprocessor needs to be valid in
wikitext to avoid being stripped out by the sanitizer. Maybe that's actually
possible, but my impression is that you are shooting for something that's
closer to the behavior
On 05/14/2014 03:22 PM, Daniel Kinzler wrote:
My patch doesn't change the handling of html.../html by the parser. As
before, the parser will pass HTML code in html.../html through only if
wgRawHtml is enabled, and will mangle/sanitize it otherwise.
Oh, I thought that you wanted to support
On 05/15/2014 04:42 PM, Daniel Kinzler wrote:
The one thing that will not work on wikis with
$wgRawHtml disabled is parsing the output of expandtemplates.
Yes, which means that it won't work with Parsoid, Flow, VE and other users.
I do think that we can do better, and I pointed out possible
On 05/17/2014 05:57 PM, Subramanya Sastry wrote:
On 05/17/2014 10:51 AM, Subramanya Sastry wrote:
So, going back to your original implementation, here are at least 3 ways I
see this working:
2. action=expandtemplates returns a html.../html for the expansion of
{{T}}, but also provides an
On 05/18/2014 02:28 AM, Subramanya Sastry wrote:
However, in his previous message, Gabriel indicated that
a property in the JSON/XML response structure might work better for
multi-part responses.
The difference between wrapper and property is actually that using inline
wrappers in the returned
On 05/19/2014 09:52 AM, Daniel Kinzler wrote:
Am 18.05.2014 16:29, schrieb Gabriel Wicke:
The difference between wrapper and property is actually that using inline
wrappers in the returned wikitext would force us to escape similar wrappers
from normal template content to avoid opening a gaping
On 05/19/2014 04:54 PM, Gabriel Wicke wrote:
The move to HTML-based (self-contained) transclusions expansions will avoid
this issue completely. That's a few months out though. Maybe we can find a
stop-gap solution that moves in that direction, without introducing special
tags
On 05/19/2014 10:19 AM, Gabriel Wicke wrote:
On 05/19/2014 04:54 PM, Gabriel Wicke wrote:
The move to HTML-based (self-contained) transclusions expansions will avoid
this issue completely. That's a few months out though. Maybe we can find a
stop-gap solution that moves in that direction
On 05/19/2014 10:55 AM, Bartosz Dziewoński wrote:
I am kind of lost in this discussion, but let me just ask one question.
Won't all of the proposed solutions, other than the one of just not
expanding transclusions that can't be expanded to wikitext, break the
original and primary purpose of
On 05/19/2014 12:46 PM, Daniel Kinzler wrote:
Am 19.05.2014 20:01, schrieb Gabriel Wicke:
On 05/19/2014 10:55 AM, Bartosz Dziewoński wrote:
I am kind of lost in this discussion, but let me just ask one question.
Won't all of the proposed solutions, other than the one of just not
expanding
On 05/20/2014 02:46 AM, Daniel Kinzler wrote:
My main reason for recycling the html tag was to not introduce a new tag
extension. domparse may occur verbatim in existing wikitext, and would break
when the tag is introduces.
The only existing mentions of this are probably us discussing it ;) In
On 05/22/2014 08:41 AM, Petr Bena wrote:
I was looking for a free (possibly open source) provider of automatic
translations for my open source application I am working on and quite
had troubles finding some. Then I realized we have a project called
wiktionary which could possibly (I was
support and developing
helper functions across JS and PHP could inform Knockoff development.
Yes, large parts of this infrastructure will be useful with Knockoff /
TAssembly as well.
Should I be saying Knockoff or Knockout?
From the RFC page, Gabriel WIcke Matthew Walker's Knockoff
templates
On 06/05/2014 11:53 AM, Nick White wrote:
As was mentioned, external resources like variously sized images
would probably be the trickiest thing to figure out good ways
around. IIRC SPDY has some inlining multiple resources in the same
packet sort of stuff, which we might be able to take
In the current discussion about git submodules vs. composer there are
several different underlying assumptions about the user's situation. I think
it would help the discussion to clarify which use cases we are dealing with.
Here is an attempt:
1) Shared hosting without shell. The user uploads
On 06/11/2014 12:29 PM, C. Scott Ananian wrote:
As Daniel hinted at, I'd like to add one more use case:
(4) prospective developers who want to do a small install for local
testing and contribute patches.
Scott I have started to summarize the use cases at
Hi all,
There are several new exciting developments in HTML templating land.
First of all, Ryan Kaldari kindly tested the Knockoff / TAssembly HTML
templating library from a Mobile perspective [1,2], and summarized his
findings on the wiki [3]. The main missing feature he identified was the
On 07/08/2014 07:28 AM, Jon Robson wrote:
This is exciting stuff. In similar news Flow and mobile now have a shared
ResourceLoaderTemplateModule [1] that supports shipping templates from
server to client.
As a next step we should explore making sure these two things are
compatible.
Yes,
On 07/08/2014 10:27 AM, Jon Robson wrote:
Tyler: What issues might you foresee these leading to...? PHP and
JavaScript have similar syntax and we use both of those...
Gabriel: It doesn't yet support JSON templates, but there is no reason
it can't. We'd just need to send a different content
On 07/08/2014 12:20 PM, Rob Lanphier wrote:
On Tue, Jul 8, 2014 at 10:27 AM, Jon Robson jdlrob...@gmail.com wrote:
In terms of benchmarks, I was thinking more along the lines of
benchmarking on the client, in particular for mobile devices which may
have less memory. This would essentially
On 07/08/2014 03:04 PM, Rob Lanphier wrote:
At a minimum, it would seem to affect deployment performance. We are much
more forgiving of things that slow down deployment than we are of things
that slow down typical page loads, but not infinitely forgiving. How much
overhead would this add to
On 07/09/2014 12:32 AM, S Page wrote:
Both handlebars (JS) and lightncandy (handlebars reimplemented in PHP)
support pre-compilation. Are the times in
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance
for pre-compilation?
No, those timings currently
On 08/10/2014 04:10 PM, Bjoern Kahl wrote:
What could cause this behavior and how should I configure my system to
prevent the deadlocks? If this is a Bug in either MediWiki or the
VisualEditor or Parsoid, how to further investigate and fix it?
In case this is a private wiki:
Did you set
On 08/28/2014 08:46 AM, Brad Jorsch (Anomie) wrote:
On Thu, Aug 28, 2014 at 11:25 AM, Aran a...@organicdesign.co.nz wrote:
I'm trying to install parsoid on Ubuntu 12. I installed nodejs from
source, but when I try and install parsoid via apt-get it fails saying
that it depends on nodejs (=
On 08/22/2014 11:34 AM, Jon Robson wrote:
Kaldari, RobLa, Trevor and I met yesterday to discuss the template RFC [1].
Sadly Gabriel was not present.
Sorry, you scheduled the meeting while I was on vacation.
Kaldari and I are very concerned that
we are blocking standardisation of a generic
On 08/28/2014 02:29 PM, Aran wrote:
Thanks I was able to use the equivs package to get parsoid to run
properly - I also then found the following link in some fine print on MW
Parsoid/Setup page which works too:
https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
Glad to
On 09/03/2014 11:08 AM, Rachel Farrand wrote:
Hello,
If you are interested in joining today's RfC discussion,
the Architecture Committee will be discussing the following RfCs:
* SOA Authentication (Chris Steipp)
https://www.mediawiki.org/wiki/Requests_for_comment/SOA_Authentication
properly.
Implementing this is not rocket science, but is currently lower priority
than other more urgent tasks.
Gabriel
--
Gabriel Wicke
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
got since last October.
Cheers,
Gabriel
--
Gabriel Wicke
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
interacts with MediaWiki through
long-established web API calls, so should be compatible with very old
MediaWiki versions.
--
Gabriel Wicke
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
the VE
/ Parsoid interaction. It will go down occasionally and without warning,
so don't rely on it for anything important.
Gabriel
--
Gabriel Wicke
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l
. The clean and information-rich HTML-based content model
in particular opens up several attractive options which are discussed in
detail in the roadmap.
Please review the roadmap and let us know what you think!
Gabriel and the Parsoid team
--
Gabriel Wicke
Senior Software Engineer
Wikimedia
would also be an improvement over the
simplistic DOM diff algorithm we currently use for change detection.
Gabriel
[1]: http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec
[2]:
http://gregory.cobena.free.fr/www/Publications/%5BICDE2002%5D%20XyDiff%20-%20published%20version.pdf
--
Gabriel Wicke
proper nesting per template without
breaking current behavior.
Gabriel
--
Gabriel Wicke
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Jens!
On 02/04/2013 05:46 AM, Jens Ohlig wrote:
I'm currently working on the Wikidata project to include Lua
functions for templates that access Wikidata entities.
I've toyed around a bit and extended LuaCommon.php with a getEntities
function and a wikibase table to hold that function.
On 02/05/2013 02:35 AM, Jens Ohlig wrote:
I'm wondering if some of the specialized functionality can be avoided by
fetching JSON data from wikibase / wikidata through a web API. This
would be more versatile, and could be used by alternative templating
systems.
This was actually my first
On 02/05/2013 10:53 AM, Brad Jorsch wrote:
On Tue, Feb 5, 2013 at 11:43 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
Apart from making the data generally available, using a web API means
that the execution can be parallelized / distributed and potentially
cached. It also tends to lead
On 02/06/2013 04:49 AM, Denny Vrandečić wrote:
There will be (actually, there is already) a web API offering the kind of
data required, and for client wikis not running on WMF infrastructure this
will eventually be the way to access the data.
For WMF clients, like the Wikipedias, our
On 02/06/2013 09:29 AM, Chris Steipp wrote:
On Wed, Feb 6, 2013 at 8:54 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
Local HTTP requests have pretty low overhead (1-2ms), but api.php
suffers from high start-up costs (35-40ms). This is more an issue with
api.php and the PHP execution model
On 02/06/2013 10:49 AM, Chris Steipp wrote:
In general, it seems to me like there will be more attacks opened up
by having lua open network requests to the api, than there would be by
defining an internal api.
Initially the use case will be providing access to the Wikidata API, not
the
On 02/06/2013 11:43 AM, Brad Jorsch wrote:
On Wed, Feb 6, 2013 at 11:54 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
It should be possible to hide optimization details like local DB access
vs. an actual HTTP request behind the same interface. A URL-based query
interface can support local
On 02/06/2013 01:30 PM, Brad Jorsch wrote:
-- Would fetch JSON from
-- http://wikidata.org/api/query/?param1=fooparam2=bar
-- if no local handler is defined and the base URL is in a whitelist
jsonObject = JSONRequest(http://wikidata.org/api/query/;,
{ param1=foo,
On 02/18/2013 04:29 AM, Tim Starling wrote:
As for the Wikidata
application -- the interface would be awkward compared to something
made specifically for interfacing Wikidata with Lua.
I am still not convinced that the interface would be awkward. A general
method like
dataTable =
?
Gabriel
[1]: http://www.mediawiki.org/wiki/Parsoid
[2]: http://www.mediawiki.org/wiki/Parsoid/Roadmap
--
Gabriel Wicke
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org
On 03/04/2013 04:00 PM, Leslie Carr wrote:
Do you want to mention node.js in the job posting? It seems to be a
big buzzword :)
Good point, we just added that extra buzz in.
Thanks!
Gabriel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 06/11/2013 05:39 PM, Jon Robson wrote:
[1]
https://www.mediawiki.org/wiki/Requests_for_comment/Deprecating_inline_styles
I left some comments at the bottom of the RFC.
Gabriel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 09/04/2013 09:59 AM, Brian Wolff wrote:
This [1] looks quite acrobatic indeed. Can’t we make better use of the
machine-readable markings provided by templates?
https://commons.wikimedia.org/wiki/Commons:Machine-readable_data
[1]
1 - 100 of 230 matches
Mail list logo
