On Wed, Feb 6, 2013 at 4:48 PM, Gabriel Wicke wrote:
> jsonData = JSONAPI.wikidata.request({ param1="foo", param2="bar" })
At that point, we may as well make it "mw.wikidata.request{
param1="foo", param2="bar" }" (or mw.ext.wikidata.request, no one has
replied to that suggestion yet).
--
Brad
On 02/06/2013 01:30 PM, Brad Jorsch wrote:
>> -- Would fetch JSON from
>> -- http://wikidata.org/api/query/?param1=foo¶m2=bar
>> -- if no local handler is defined and the base URL is in a whitelist
>> jsonObject = JSONRequest("http://wikidata.org/api/query/";,
>> { param1="
On Wed, Feb 6, 2013 at 4:04 PM, Gabriel Wicke wrote:
> On 02/06/2013 11:43 AM, Brad Jorsch wrote:
>> On Wed, Feb 6, 2013 at 11:54 AM, Gabriel Wicke wrote:
>>>
>>> It should be possible to hide optimization details like local DB access
>>> vs. an actual HTTP request behind the same interface. A UR
On 02/06/2013 11:43 AM, Brad Jorsch wrote:
> On Wed, Feb 6, 2013 at 11:54 AM, Gabriel Wicke 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 handlers for sp
On Wed, Feb 6, 2013 at 11:54 AM, Gabriel Wicke 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 handlers for specific URL prefixes.
Or the interface can just l
Please don't forget about the hybrid approach -- API supports FauxRequests
- so an API call can be made without doing a web call, but an internal one
instead, without any json or startup overhead:
http://www.mediawiki.org/wiki/API:Calling_internally
On Wed, Feb 6, 2013 at 2:08 PM, Gabriel Wicke
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 Medi
On Wed, Feb 6, 2013 at 10:04 AM, Bjoern Hoehrmann wrote:
> * Chris Steipp wrote:
>>On Wed, Feb 6, 2013 at 8:54 AM, Gabriel Wicke 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
On 02/06/2013 09:29 AM, Chris Steipp wrote:
> On Wed, Feb 6, 2013 at 8:54 AM, Gabriel Wicke 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 than with HTTP th
* Chris Steipp wrote:
>On Wed, Feb 6, 2013 at 8:54 AM, Gabriel Wicke 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 than with HTTP though, and might be
>> i
On Wed, Feb 6, 2013 at 8:54 AM, Gabriel Wicke 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 than with HTTP though, and might be
> improved in the future.
I w
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 dec
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 decision was not to use HTTP web
requests, but to internally
On Tue, Feb 5, 2013 at 2:43 PM, Gabriel Wicke wrote:
>> It would also mean that MediaWiki would be making uncontrolled API
>> calls *during the page parse*.
>
> To me it is not clear why a Wikidata web API would be less controlled
> than a Wikidata Lua API with direct access to the DB.
Oh. Earlie
On 02/05/2013 10:53 AM, Brad Jorsch wrote:
> On Tue, Feb 5, 2013 at 11:43 AM, Gabriel Wicke 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 to narrow interfaces
On Tue, Feb 5, 2013 at 11:43 AM, Gabriel Wicke 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 to narrow interfaces with explicit
> handling of state.
It would als
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
On Tue, Feb 5, 2013 at 5:31 AM, Jens Ohlig wrote:
>
> Am 04.02.2013 um 18:03 schrieb Brad Jorsch :
>
>> On Mon, Feb 4, 2013 at 8:46 AM, Jens Ohlig wrote:
>>>
>>> Here are my questions:
>>> 1. Is there an easy way to add your own Lua functions (that call PHP Api
>>> functions) to Scribunto other
Am 04.02.2013 um 18:03 schrieb Brad Jorsch :
> On Mon, Feb 4, 2013 at 8:46 AM, Jens Ohlig wrote:
>>
>> Here are my questions:
>> 1. Is there an easy way to add your own Lua functions (that call PHP Api
>> functions) to Scribunto other than writing them into LuaCommon.php?
>
> Yes. Probably th
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 functio
2013/2/4 Brad Jorsch :
> You'd add your library object in Lua as a child of the "mw" object.
Sounds like same little mistake we are already "dealing" with in
JavaScript, see:
http://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/JavaScript#Place_for_Extensions_Objects_in_JavaScript_20654
P
On Mon, Feb 4, 2013 at 8:46 AM, Jens Ohlig wrote:
>
> Here are my questions:
> 1. Is there an easy way to add your own Lua functions (that call PHP Api
> functions) to Scribunto other than writing them into LuaCommon.php?
Yes. Probably the best example to look at right now is gerrit change
47109
Hello,
I guess this can be answered by Tim or Victor, but I'm grateful for any
pointers that can help me with a rather specific problem with Scribunto.
I'm currently working on the Wikidata project to include Lua functions for
templates that access Wikidata entities.
I've toyed around a bit an
23 matches
Mail list logo
