Last modified: 2010-05-15 15:37:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3450 - Special pages should have a machine-readable format
Special pages should have a machine-readable format
Status: RESOLVED DUPLICATE of bug 14869
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.5.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-13 01:19 UTC by Jamie Bliss
Modified: 2010-05-15 15:37 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Special:Allpages implementation (for XML) (7.36 KB, patch)
2005-09-13 01:26 UTC, Jamie Bliss
Details
Special:Allpages implementation (for XML) (14.86 KB, patch)
2005-09-13 22:11 UTC, Jamie Bliss
Details

Description Jamie Bliss 2005-09-13 01:19:16 UTC
The special pages should be able to be read by an application (such as a non-web
client), whether it be in XML, RDF, or some other format.

This obviously excludes Special:Export and Special:Import.
Comment 1 Jamie Bliss 2005-09-13 01:26:46 UTC
Created attachment 880 [details]
Special:Allpages implementation (for XML)

This is the first of several patches implementing this bug using XML. They are
triggered by including "xml=yes" in the URL query.

This one handles Special:Allpages. It returns exactly the same information as
HTML (this includes initial range lists and such). None of the logic has
changed.

Also, in XML mode, it returns an HTTP status code of 300 Multiple Choices for
range listings (in addition to a flag in the XML).
Comment 2 Brion Vibber 2005-09-13 01:36:41 UTC
The special cases everywhere in this code are pretty ugly and will be 
hard to maintain.

I'd recommend reworking this to a model-view system, with separate 
classes for handling HTML output and XML output, both separate from the 
database-reading work.
Comment 3 Jamie Bliss 2005-09-13 01:40:38 UTC
(In reply to comment #2)
> The special cases everywhere in this code are pretty ugly and will be 
> hard to maintain.
> 
> I'd recommend reworking this to a model-view system, with separate 
> classes for handling HTML output and XML output, both separate from the 
> database-reading work.

I'll see what I can do with that. Currently, that special page is not OO, just a
collection of functions.

What I'm thinking is create a "PageLister" class (not final name!) and implement
it for XML and HTML. Pass it to each of the functions, etc.
Comment 4 Jamie Bliss 2005-09-13 22:11:37 UTC
Created attachment 889 [details]
Special:Allpages implementation (for XML)

Added object described. Should be working. (Although such extensive changes
should be tested.)
Comment 5 Daniel Kinzler 2005-10-24 23:18:36 UTC
Please compare with Bug #3676, where I provided a patch for adding CSV support
to most special pages with minimal effort.
Comment 6 Jamie Bliss 2005-10-24 23:59:16 UTC
(In reply to comment #5)
> Please compare with Bug #3676, where I provided a patch for adding CSV support
> to most special pages with minimal effort.

I should note that unlike CSV, this is geared towards applications that can use
XML with great ease (eg, AJAX apps). This is not only bots, but client-side
readers as well.

XML is also less ambiguous. You can specify exactly what each piece of data is,
instead of infering that from it's position relative to other data.

There is place for both. (CSV is simpler, XML has more well-distributed APIs.)
Cooperation betweeen these two ideas would be very good. (gen=xml?)
Comment 7 Rob Church 2007-01-15 14:38:59 UTC
I suspect we want to phase this out in favour of the new machine-readable API.
Comment 8 Jamie Bliss 2007-01-16 22:22:53 UTC
Sure. Then make this a tracking bug for special pages that do/don't comply.

My concern is that if the data itself isn't easily parsed, then it amounts to
glorified screen-scraping.

If the API is directed at articles (in wikitext), then how do special pages fit
into it?
Comment 9 Roan Kattouw 2007-07-03 15:47:47 UTC
(In reply to comment #8)
> If the API is directed at articles (in wikitext), then how do special pages fit
> into it?
The API currently implements something similar to Special:Allpages (but with more filtering options), and most other special pages (or derivations thereof) are also implemented.
Comment 10 Roan Kattouw 2008-09-06 22:00:04 UTC

*** This bug has been marked as a duplicate of bug 14869 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links