query.php scheduled to die Monday, August 25

[Brion Vibber-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As you may know, the current MediaWiki API was based on an earlier
interface, the BotQuery extension accessed via query.php.

During development of the new API, the old query.php was left in place
on Wikimedia's sites to provide backwards-compatibility for tools and
user scripts using it.

However it's a bit of a burden to keep it around -- being nearly
unmaintained it suffers from "bitrot":

* Queries sometimes break due to backend changes

* Security problems are sometimes discovered and must be patched


We've been reluctant to just turn it off since some user scripts still
use it (Lupin's Popups are rumored to be the most popular such), but I'd
like to go ahead and plan to kill it.

I'm currently scheduling the Death of query.php for Monday, August 25 --
a little less than 4 weeks from today.

This gives interested parties a chance to either migrate their scripts
to the current API ahead of time, or to start work on an adaptor to
replace query.php -- transforming queries to send them to the new API
and transforming the results back to a format compatible with the old one.

- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiQ760ACgkQwRnhpk1wk46VGwCeOLp5Ynuw48ikLv8YztyB0kIc
eKoAnjPhey51pkojh7mTT4j7BYz95gYZ
=QZC+
-----END PGP SIGNATURE-----

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Magnus Manske-2]

On Wed, Jul 30, 2008 at 11:48 PM, Brion Vibber <brion@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> As you may know, the current MediaWiki API was based on an earlier
> interface, the BotQuery extension accessed via query.php.
>
> During development of the new API, the old query.php was left in place
> on Wikimedia's sites to provide backwards-compatibility for tools and
> user scripts using it.
>
> However it's a bit of a burden to keep it around -- being nearly
> unmaintained it suffers from "bitrot":
>
> * Queries sometimes break due to backend changes
>
> * Security problems are sometimes discovered and must be patched
>
>
> We've been reluctant to just turn it off since some user scripts still
> use it (Lupin's Popups are rumored to be the most popular such), but I'd
> like to go ahead and plan to kill it.
>
> I'm currently scheduling the Death of query.php for Monday, August 25 --
> a little less than 4 weeks from today.
>
> This gives interested parties a chance to either migrate their scripts
> to the current API ahead of time, or to start work on an adaptor to
> replace query.php -- transforming queries to send them to the new API
> and transforming the results back to a format compatible with the old one.

So far, I've found two things query.php does which api.php does not:
* give bit depth of image (not exactly critical for my purposes, though)
* for redirect pages, give the redirect target (this could affect a
tool of mine)

I'll report more as I find them.

Magnus

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Bryan Tong Minh]

On Thu, Jul 31, 2008 at 9:36 PM, Magnus Manske
<magnusmanske@...> wrote:
> So far, I've found two things query.php does which api.php does not:
> * give bit depth of image (not exactly critical for my purposes, though)
I may or may not fix this tonight.

> * for redirect pages, give the redirect target (this could affect a
> tool of mine)
>
<http://en.wikipedia.org/w/api.php?action=query&titles=-100&prop=info&redirects>

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Magnus Manske-2]

On Thu, Jul 31, 2008 at 8:56 PM, Bryan Tong Minh
<bryan.tongminh@...> wrote:

> On Thu, Jul 31, 2008 at 9:36 PM, Magnus Manske
> <magnusmanske@...> wrote:
>> So far, I've found two things query.php does which api.php does not:
>> * give bit depth of image (not exactly critical for my purposes, though)
> I may or may not fix this tonight.
>
>> * for redirect pages, give the redirect target (this could affect a
>> tool of mine)
>>
> <http://en.wikipedia.org/w/api.php?action=query&titles=-100&prop=info&redirects>

Ah! Thanks.

I also see that some query.php functions return properties "touched"
(not the same as timestamp, apparently) and "revid". This is not
critical AFAIK, and could be replaced with another query; that,
however, seems inefficient.

Magnus

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Paolo Liberatore]

One thing I think cannot be done directly in api.php is
to return the pages that embed a *list* of templates.

So for example if I have template1, template2, template3,
with query.php I am able to return all pages embedding any
of these, while in api.php I have to make a query for
each one.

The problem is that eititle only accepts one title, and
that titles= is now ignored.

[[en:User:Tizio]]
Paolo Liberatore

On Thu, 31 Jul 2008, Magnus Manske wrote:

> On Wed, Jul 30, 2008 at 11:48 PM, Brion Vibber <brion@...> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > As you may know, the current MediaWiki API was based on an earlier
> > interface, the BotQuery extension accessed via query.php.
> >
> > During development of the new API, the old query.php was left in place
> > on Wikimedia's sites to provide backwards-compatibility for tools and
> > user scripts using it.
> >
> > However it's a bit of a burden to keep it around -- being nearly
> > unmaintained it suffers from "bitrot":
> >
> > * Queries sometimes break due to backend changes
> >
> > * Security problems are sometimes discovered and must be patched
> >
> >
> > We've been reluctant to just turn it off since some user scripts still
> > use it (Lupin's Popups are rumored to be the most popular such), but I'd
> > like to go ahead and plan to kill it.
> >
> > I'm currently scheduling the Death of query.php for Monday, August 25 --
> > a little less than 4 weeks from today.
> >
> > This gives interested parties a chance to either migrate their scripts
> > to the current API ahead of time, or to start work on an adaptor to
> > replace query.php -- transforming queries to send them to the new API
> > and transforming the results back to a format compatible with the old one.
>
> So far, I've found two things query.php does which api.php does not:
> * give bit depth of image (not exactly critical for my purposes, though)
> * for redirect pages, give the redirect target (this could affect a
> tool of mine)
>
> I'll report more as I find them.
>
> Magnus
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api@...
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Roan Kattouw]

Paolo Liberatore schreef:
> One thing I think cannot be done directly in api.php is
> to return the pages that embed a *list* of templates.
>
> So for example if I have template1, template2, template3,
> with query.php I am able to return all pages embedding any
> of these, while in api.php I have to make a query for
> each one.
>  
There's a very good reason for that: queries with dozens of values for
eititle become very inefficient very fast.
> The problem is that eititle only accepts one title, and
> that titles= is now ignored.
That change was announced months ago on this list (search for
"backlinks" in the subject).

Roan Kattouw (Catrope)

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Roan Kattouw]

Magnus Manske schreef:
> Ah! Thanks.
> I also see that some query.php functions return properties "touched"
> (not the same as timestamp, apparently) and "revid". This is not
> critical AFAIK, and could be replaced with another query; that,
> however, seems inefficient.
Since touched is provided by prop=info and revid by prop=revisions (the
latter in a slightly different format), you could just use
generator=whatever&prop=info|revisions here.

Roan Kattouw (Catrope)

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Brion Vibber-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brion Vibber wrote:
> During development of the new API, the old query.php was left in place
> on Wikimedia's sites to provide backwards-compatibility for tools and
> user scripts using it.
>
> However it's a bit of a burden to keep it around -- being nearly
> unmaintained it suffers from "bitrot":
[snip]
> I'm currently scheduling the Death of query.php for Monday, August 25 --
> a little less than 4 weeks from today.

...now done.

query.php is dead! Long live api.php!

> This gives interested parties a chance to either migrate their scripts
> to the current API ahead of time, or to start work on an adaptor to
> replace query.php -- transforming queries to send them to the new API
> and transforming the results back to a format compatible with the old one.

Guess nobody wanted an adaptor that badly. :)

- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkizNNEACgkQwRnhpk1wk45eXgCfSutan8ovlmLwMLBYFGixo1EW
IzsAnR6k3JIX48HkfzhgWqJnFGuoyMmI
=cx4Q
-----END PGP SIGNATURE-----

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api