When we say "API" we mean "bot API", i.e., "a web-based API provided for third parties to read data from (and possibly write data to) the wiki in a programmatic fashion, either anonymously or via a user account".
Ok, so under that strict definition, the answer to the original question of whether the internal core code would ever use it is obviously "no". If you define "the API" as including the externalized HTTP mechanism by which the functionality is accessed, then of course it makes no sense for core code to use it per all the reasons previously mentioned. Case closed, points granted. :)
On the other hand, if you consider the supporting PHP classes through which api.php makes its calls as part of "the API" then I still contend that there are probably cases where it would be easier or simpler (or both) to just use it than say construct all the database queries onesself.
Personally, I'm not enough of a purist to argue for or against making "all" core code utilize some standard set of classes to encapsulate a data model, except to say that there are good reasons why MW doesn't employ an ORM, and those reasons are probably applicable to the argument against a one-size-fits-all API backend.
-- Jim
On Thu, Aug 21, 2008 at 5:22 PM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On Fri, Aug 22, 2008 at 12:01 AM, Roan Kattouw roan.kattouw@home.nl wrote:
Just to clarify again: the API and the UI call *the same functions*, but present the results differently. That's why there's *nothing to gain whatsoever* in letting the UI call the API.
In theory...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l