Daniel Friesen wrote:
> I wanted to use runkit but had issues installing
> it. So I ended up messing with php's horrid proc_open to sandbox it in
> another process to act as the vm in the case my system needs to extract
> info from the wiki (not for virtualizing the actual wiki, that is done
>
--
From: "Dmitriy Sintsov"
Sent: Friday, June 04, 2010 11:35 AM
To: "Happy-melon"
Subject: Re: [Wikitech-l] Reasonably efficient interwiki transclusion
> * Happy-melon [Fri, 4 Jun 2010 11:10:04 +0100]:
>>
>>
--
From: "Dmitriy Sintsov"
Sent: Friday, June 04, 2010 11:01 AM
To: "Happy-melon" ; "Wikimedia developers"
Subject: Re: [Wikitech-l] Reasonably efficient interwiki transclusion
> * Happy-melon [Fri, 4 Jun 201
* Happy-melon [Fri, 4 Jun 2010 10:03:14 +0100]:
>
> "Dmitriy Sintsov" wrote in message
> news:1006208056.1275619880.71836632.61...@mcgi66.rambler.ru...
> > * Happy-melon [Fri, 4 Jun 2010 00:33:30
+0100]:
> >>
> >>
> >> One way to achieve this would be to develop the MediaWiki class to
> >> actu
"Dmitriy Sintsov" wrote in message
news:1006208056.1275619880.71836632.61...@mcgi66.rambler.ru...
> * Happy-melon [Fri, 4 Jun 2010 00:33:30 +0100]:
>>
>>
>> One way to achieve this would be to develop the MediaWiki class to
>> actually
>> be what it originally promised: an object representing a
* Happy-melon [Fri, 4 Jun 2010 00:33:30 +0100]:
>
>
> One way to achieve this would be to develop the MediaWiki class to
> actually
> be what it originally promised: an object representing a wiki, of
which
> there can in principle be more than one instantiated at any one time.
> Configuration opt
Platonides wrote:
> Daniel Friesen wrote:
>
>> ^_^ "hackish" isn't that bad in some sense. I'm currently experimenting
>> with some farm code that works completely outside of MediaWiki rather
>> than as a extension sitting inside of it. Using a sandbox it can get
>> access to the MediaWiki in
"Dmitriy Sintsov" wrote in message
news:830714463.1275562997.168145444.10...@mcgi21.rambler.ru...
> * Roan Kattouw [Tue, 25 May 2010 20:58:54
> +0200]
>>
> Having a something like FarmRequest or FarmApi classes would be a great
> think for wiki farms (I run a small one).
> Probably also would h
Daniel Friesen wrote:
> ^_^ "hackish" isn't that bad in some sense. I'm currently experimenting
> with some farm code that works completely outside of MediaWiki rather
> than as a extension sitting inside of it. Using a sandbox it can get
> access to the MediaWiki install and extract info from i
Dmitriy Sintsov wrote:
> * Roan Kattouw [Tue, 25 May 2010 20:58:54
> +0200]:
>
>> 2010/5/25 Aryeh Gregor :
>>
>>> Having Wikimedia servers send HTTP requests to each other instead of
>>> just doing database queries does not sound like a great idea to me.
>>> You're hitting several extra s
* Roan Kattouw [Tue, 25 May 2010 20:58:54
+0200]:
> 2010/5/25 Aryeh Gregor :
> > Having Wikimedia servers send HTTP requests to each other instead of
> > just doing database queries does not sound like a great idea to me.
> > You're hitting several extra servers for no reason, including extra
> >
I have updated my proposal with a fourth version [1]
I am still waiting for comments from Tim Starling. I have contacted
him on IRC for this.
[1]
http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_transclusion#Fourth_version_.(to_be_discussed)
--
Peter Potrowl
http://www.
Peter17 wrote:
> I didn't set $wgUploadPath. Just $wgUseInstantCommons = true; The
> images URLs are actually transformed to remote URLs:
>
> I work on my own local wiki, which address is
> http://localhost/mediawiki/ and transcluding
> {{mediawikiwiki::User:Peter17}} which contains
> [[File:Exqui
@peter: here a recent thread into MediaWiki-API ml about API and sections:
http://lists.wikimedia.org/pipermail/mediawiki-api/2010-May/subject.html
No mention of labelled sections used by #lst exstesion ... :-( but
remember the name of ThomasV as a reference.
Alex
___
2010/5/26 Jim Tittsler :
> On 2010-05-25 23:41, Peter17 wrote:
>> 2010/5/25 Platonides :>
>>> > Seems it doesn't work so well. It was inadvertedly broken for wikitext
>>> > transclusions when the interwiki points to the nice url. See
>>> > 'wgEnableScaryTranscluding and Templates/Images?' thread at
On 2010-05-25 23:41, Peter17 wrote:
> 2010/5/25 Platonides :>
>> > Seems it doesn't work so well. It was inadvertedly broken for wikitext
>> > transclusions when the interwiki points to the nice url. See
>> > 'wgEnableScaryTranscluding and Templates/Images?' thread at mediawiki-l
>> >
> Well, in my
On Tue, May 25, 2010 at 5:50 PM, Platonides wrote:
> There are imho fewer variables set by the caller wiki, which could be
> passed with the query.
I don't get what you're saying here.
> For intra-Wikimedia query, they could directly ask an apache. They can
> even send the query to localhost.
>
On Tue, May 25, 2010 at 5:50 PM, Platonides wrote:
>> But I guess that's much better handled by just using a proper export,
>> and having the templates included in that, so never mind.
>
> Yes. Perhaps they could have a Special:ImportFromRemote to do one-click
> imports.
>
And this is different f
Aryeh Gregor wrote:
>> Ok, I will keep this in mind. Parsing the template on the home wiki
>> seems necessary because it can use other templates hosted on that wiki
>> to render correctly... I think it is the most logical way to do, isn't
>> it?
>
> I think parsing the template on the local wiki i
On Tue, May 25, 2010 at 3:48 PM, Roan Kattouw wrote:
> Also note that you wouldn't technically be parsing, just preprocessing
> on the home wiki, which is certain to be less expensive (how much less
> I don't know)
This is a good point.
> and that you'd be doing this on some wiki anyway, so
> on
On Tue, May 25, 2010 at 8:58 PM, Roan Kattouw wrote:
> To the point of whether parsing on the on the distant wiki makes more
> sense: I guess there are points to be made both ways. I originally
> subscribed to the idea of parsing on the home wiki so expanding the
> same template with the same argu
2010/5/25 Aryeh Gregor :
> Templates will often miss the parser cache, because different
> invocations will use different parameters. Even *with* the parser
> cache, parsing is *still* one of the most expensive operations
> Wikimedia does, so I'm not so sanguine.
>
I wasn't talking about the templ
On Tue, May 25, 2010 at 2:58 PM, Roan Kattouw wrote:
> This is true if, indeed, all parsing is done on the distant wiki.
> However, if parsing is done on the home wiki, you're not simply
> requesting data that's ready-baked in the DB and API calls make sense.
That's true -- if parsing is done on
2010/5/25 Aryeh Gregor :
> Having Wikimedia servers send HTTP requests to each other instead of
> just doing database queries does not sound like a great idea to me.
> You're hitting several extra servers for no reason, including extra
> requests to an application server. On top of that, you're ca
(I'm going to use "local wiki" here for what Peter is calling "distant
wiki", and "foreign wiki" for what he's calling "home wiki". This
seems to better match the terminology we use for Commons.)
On Tue, May 25, 2010 at 7:41 AM, Peter17 wrote:
> Yes. The shared database would be only for invalid
On 25 May 2010 15:30, Platonides wrote:
> church.of.emacs.ml wrote:
>> However, you'd have to worry that each distant wiki uses only a fair
>> amount of the home wiki server's resources. E.g. set a limit of
>> inclusions (that limit would have to be on the home-wiki-server-side)
>> and disallow in
church.of.emacs.ml wrote:
> However, you'd have to worry that each distant wiki uses only a fair
> amount of the home wiki server's resources. E.g. set a limit of
> inclusions (that limit would have to be on the home-wiki-server-side)
> and disallow infinite loops (they're always fun).
Infinite lo
Aryeh Gregor wrote:
> On Mon, May 24, 2010 at 8:27 PM, Q wrote:
>> I would have to suggest to not go the shared database route unless the
>> code can be fixed so that shared databases actually work with all of the
>> DB backends.
>
> I don't see why it shouldn't be easy to get it working with all
On 05/25/2010 01:41 PM, Peter17 wrote:
> 2010/5/25 church.of.emacs.ml :
>>
>> 2. Parsing the wikitext at the home wiki makes it more difficult to use
>> site magic words, e.g. {{CONTENTLANGUAGE}}. You'd have to pass one each
>> and everyone as a template parameter (e.g.
>> {{homewiki::templatename|
On Tue, May 25, 2010 at 7:41 AM, Peter17 wrote:
> Mmmh sorry, I'm not really sure I understand... My suggestion is
> to use a shared database that would store the remote calls, not the
> content of the pages... In my mind, fetching the distant pages would
> be done through the API, not by acce
>
> About the question from Alex about transcluding sections: is it
> possible to request only a section through the API? I searched about
> this but didn't find :(
>
> --
> Peter Potrowl
>
Ask ThomasV, #lst is particularly cared by him, to deepest level of
knowledge! I guess he met too your same
2010/5/25 Platonides :>
> Seems it doesn't work so well. It was inadvertedly broken for wikitext
> transclusions when the interwiki points to the nice url. See
> 'wgEnableScaryTranscluding and Templates/Images?' thread at mediawiki-l
>
Well, in my tests, images are well included because I enabled
$
On Mon, May 24, 2010 at 8:27 PM, Q wrote:
> I would have to suggest to not go the shared database route unless the
> code can be fixed so that shared databases actually work with all of the
> DB backends.
I don't see why it shouldn't be easy to get it working with all DB
backends. But in any cas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 5/24/2010 6:42 PM, church.of.emacs.ml wrote:
> Hi,
>
> On 05/24/2010 04:44 PM, Peter17 wrote:
>> It is now open for comments, so, could you please read it and let me
>> know about your remarks and suggestions, on this list and/or on the
>> talk p
On Mon, May 24, 2010 at 7:42 PM, church.of.emacs.ml
wrote:
> Hi,
>
> On 05/24/2010 04:44 PM, Peter17 wrote:
>> It is now open for comments, so, could you please read it and let me
>> know about your remarks and suggestions, on this list and/or on the
>> talk page?
>
> first of all, I let me tell y
Hi,
On 05/24/2010 04:44 PM, Peter17 wrote:
> It is now open for comments, so, could you please read it and let me
> know about your remarks and suggestions, on this list and/or on the
> talk page?
first of all, I let me tell you that I'm really excited about this
project. It may very well revolut
http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_transclusion#Good_points
Seems it doesn't work so well. It was inadvertedly broken for wikitext
transclusions when the interwiki points to the nice url. See
'wgEnableScaryTranscluding and Templates/Images?' thread at mediawi
On Mon, May 24, 2010 at 18:48, Chad wrote:
> On Mon, May 24, 2010 at 11:18 AM, Amir E. Aharoni
> wrote:
>> The title of the subject is a bit confusing. "Interwiki", for better
>> or worse, refers to interlanguage links.
>
> No it doesn't. Interwiki links don't have to be interlanguage
> links. In
On Mon, May 24, 2010 at 11:18 AM, Amir E. Aharoni
wrote:
> On Mon, May 24, 2010 at 17:44, Peter17 wrote:
>>
>> Hello to all!
>>
>> I'm a French student and I am participating the Google Summer of Code
>> this year on Mediawiki!
>>
>> My mentor is Roan Kattouw (Catrope) and my subject is "Reasonab
On Mon, May 24, 2010 at 17:44, Peter17 wrote:
>
> Hello to all!
>
> I'm a French student and I am participating the Google Summer of Code
> this year on Mediawiki!
>
> My mentor is Roan Kattouw (Catrope) and my subject is "Reasonably
> efficient interwiki transclusion". You can see my application
2010/5/24 Peter17
> Hello to all!
>
> I'm a French student and I am participating the Google Summer of Code
> this year on Mediawiki!
>
> My mentor is Roan Kattouw (Catrope) and my subject is "Reasonably
> efficient interwiki transclusion". You can see my application page
> here: [1].
>
Thanks P
Hello to all!
I'm a French student and I am participating the Google Summer of Code
this year on Mediawiki!
My mentor is Roan Kattouw (Catrope) and my subject is "Reasonably
efficient interwiki transclusion". You can see my application page
here: [1].
I have already discussed with my mentor and
42 matches
Mail list logo
