Special:All pages broken at about 03:00 UTC this morning

[Aryeh Gregor]

On Wed, Aug 20, 2008 at 2:20 PM, Roan Kattouw <roan.kattouw@...> wrote:
> About enabling the edit API on Wikipedia: I think it's ready to go. The
> only real problem it currently has is that action=edit doesn't handle
> aborts by hooks too well; the edit will be aborted, but the client will
> only get a vague "A hook aborted the action" (or something along those
> lines) error. A hook that allows for aborting the edit with a meaningful
> error message has been added (APIEditBeforeSave), but AFAIK it's
> currently only used by ConfirmEdit (and only because I migrated it
> myself). Similarly, extensions influencing other actions may rely on UI
> hooks that the API bypasses altogether.

Um, why are you adding an API-specific hook for this?  Shouldn't it be
a backend hook?  I'm not sure why there should be *any* API hooks,
actually, since the API should just be presenting backend information
in a standard format.  Extensions should never want to change the
format that's returned, as far as I can imagine, since it's supposed
to be uniform across all wikis.  They should only want to change the
actual info, which should be done on the backend level.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Brion Vibber-3]

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

Aryeh Gregor wrote:

> On Wed, Aug 20, 2008 at 2:20 PM, Roan Kattouw <roan.kattouw@...> wrote:
>> About enabling the edit API on Wikipedia: I think it's ready to go. The
>> only real problem it currently has is that action=edit doesn't handle
>> aborts by hooks too well; the edit will be aborted, but the client will
>> only get a vague "A hook aborted the action" (or something along those
>> lines) error. A hook that allows for aborting the edit with a meaningful
>> error message has been added (APIEditBeforeSave), but AFAIK it's
>> currently only used by ConfirmEdit (and only because I migrated it
>> myself). Similarly, extensions influencing other actions may rely on UI
>> hooks that the API bypasses altogether.
>
> Um, why are you adding an API-specific hook for this?  Shouldn't it be
> a backend hook?  I'm not sure why there should be *any* API hooks,
> actually, since the API should just be presenting backend information
> in a standard format.  Extensions should never want to change the
> format that's returned, as far as I can imagine, since it's supposed
> to be uniform across all wikis.  They should only want to change the
> actual info, which should be done on the backend level.

The way it _should_ be working is something like this:

1) There's a backend ("controller") class for performing edits. This has
hook points for things like aborting or altering edits (spam checks,
captcha, etc)

2) There's a frontend ("view") class for handling the HTML edit form.
This has hook points for customizing the form output, checking custom
input, and presenting UI for error conditions ("you hit spam!" or "you
need to submit this extra form")

3) There's another frontend ("view") class for handling the API's edit
interface. This _might_ also have hook points for handling special
input/output and custom error formatting, though _ideally_ such stuff
should be able to use existing I/O channels specified in the API (spam
hit just raises an error conditions; captcha hits have an existing
channel for saying "show this and respond to it").


Currently the EditPage class mixes a fair chunk of backend and UI, as do
the edit filter hooks for spam blacklisting, CAPTCHAs, etc, so it's a
bit icky. There's been some refactoring in the course of creating the
edit API (as there was much refactoring to Special:Userlogin when the
API's login modules were being created), but it remains incomplete.

(At least the raw page data storage model isn't mixed into EditPage! :)

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

iEYEARECAAYFAkisaV8ACgkQwRnhpk1wk47AswCgxnUPZhA5+Kxg0tuGdxJ0Z19q
SIEAoKNhI5/SCjIE8tqDPmPTGprwmcW8
=nPgB
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Bryan Tong Minh]

On Wed, Aug 20, 2008 at 7:58 PM, Victor Vasiliev <vasilvv@...> wrote:
[...]

> And also, I went through
> the mediawiki-api archives and found about 9 breaking changes for API.
> Pretty stable, isn't it? :)
> --vvv
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@...
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

But far less recently. The API has been in development phase for the
last two years or so with many modules added over time which were not
all as consistent as we would want it to be. But I think now that we
are entering a more stable phase where large portions that need to be
covered are covered and not much change can be expected.

As for the edit api I'm not really sure whether it is ready. It has
been some time that I last looked at it. If I remember correctly there
are still some problems left with hooks that I'd rather see fixed. I
did fix some myself some time ago but I don't recall whether I fixed
all of them.

Bryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Brion Vibber schreef:

>
>> Um, why are you adding an API-specific hook for this?  Shouldn't it be
>> a backend hook?  I'm not sure why there should be *any* API hooks,
>> actually, since the API should just be presenting backend information
>> in a standard format.  Extensions should never want to change the
>> format that's returned, as far as I can imagine, since it's supposed
>> to be uniform across all wikis.  They should only want to change the
>> actual info, which should be done on the backend level.
>>    
>
> The way it _should_ be working is something like this:
>
> 1) There's a backend ("controller") class for performing edits. This has
> hook points for things like aborting or altering edits (spam checks,
> captcha, etc)
>
> 2) There's a frontend ("view") class for handling the HTML edit form.
> This has hook points for customizing the form output, checking custom
> input, and presenting UI for error conditions ("you hit spam!" or "you
> need to submit this extra form")
>
> 3) There's another frontend ("view") class for handling the API's edit
> interface. This _might_ also have hook points for handling special
> input/output and custom error formatting, though _ideally_ such stuff
> should be able to use existing I/O channels specified in the API (spam
> hit just raises an error conditions; captcha hits have an existing
> channel for saying "show this and respond to it").
>
>
> Currently the EditPage class mixes a fair chunk of backend and UI, as do
> the edit filter hooks for spam blacklisting, CAPTCHAs, etc, so it's a
> bit icky. There's been some refactoring in the course of creating the
> edit API (as there was much refactoring to Special:Userlogin when the
> API's login modules were being created), but it remains incomplete.
>
> (At least the raw page data storage model isn't mixed into EditPage! :)

Yup, EditPage is a nightmare. I have a half-written Edit class lying
around that's supposed to contain the backend part of EditPage. It's far
from complete, however, and currently on hold. I'd be happy to send
anyone interested in continuing that rewrite before I do (which could
take some time) my unfinished work.

About the hooks: most hooks should be in the backend, yes. However,
extensions like ConfirmEdit need to return certain information (CAPTCHA
URLs) to the user. There's a UI hook to do that in the UI, and there's
an API hook to return that information to API users. Now CE is kind of
unique that way, and the API does honor most hooks in EditPage.php, it
just doesn't provide a way to pass a meaningful error message back to
the user. The problem here is that since EditPage doesn't properly
separete UI and backend, neither do its hooks. For instance, the hook
that checks whether an edit is spam is supposed to come up with an HTML
(!) error message, which it has to insert into the EditPage object
somewhere. Of course that's deeply evil from the API's perspective.
There's a similar issue with the upload code (actually, it's even worse)
which necessitates a big rewrite before an action=upload module can even
be written. Luckily (for me), Bryan committed to that task (thanks again).

The recurring theme here is that phase4 (if we ever go there) requires a
rethinking of EditPage.php (and SpecialPreferences.php, BTW).

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Aryeh Gregor schreef:

> On Wed, Aug 20, 2008 at 1:58 PM, Victor Vasiliev <vasilvv@...> wrote:
>  
>> Yes, you just have to worry that query.php is replaced with api.php,
>> which may be then replaced with something else. And also, I went through
>> the mediawiki-api archives and found about 9 breaking changes for API.
>> Pretty stable, isn't it? :)
>>    
>
> I don't understand why there are ever breaking changes in the API.
> THE API SHOULD NEVER EVER EVER CHANGE.  IT SHOULD BE A STABLE
> INTERFACE.  There needs to be a policy, set in stone, not negotiable,
> that behavior for a given API query should NEVER change in an
> incompatible fashion.  If something is inconsistent it should be
> deprecated and a new function instituted to replace it.  The old
> deprecated way could then be marked for a few years (say, three years,
> or at least one year) before finally being removed.  Authors of bot
> frameworks should be encouraged to write code checking for
> <deprecated> or whatever and having their framework raise a warning of
> some kind to inform them that they should update it.
>
> This really seems like a no-brainer to me.  But, I'm not an API
> developer, so . . .

Those 9 breaking changes sound far worse than they are. Most breaking
changes are allowed as such because they *technically* change the API's
behavior, but in a way that's unlikely to bother people who use decent
frameworks. Anyway, here they are:

[1] was done on the request of an end user and to achieve consistency
across modules. As I pointed out to that user, I doubted that anyone
actually *used* the old behavior, or would even notice when it was changed.
[2] was done to prevent blowing up databases with LIMITless queries. The
limit/continue interface has existed for other modules for ages, and
supporting it for additional modules on the client side should be trivial.
[3] broke something 24 hours after introducing it and made it actually
do something useful
[4] was announced by Yuri 10 months before hybrid support (i.e. support
for both the old and the new parameter) was finally abandoned
[5] and [6] handle erroneous parameters more gracefully, which was a
much-requested improvement but technically broke BC, because erroneous
requests would return a warning rather than an error
[7] was, again, a few days old feature that was moved to a separate
module. Anyone quick enough to support such a young feature can change
one word in the module call equally quickly
[8] was another change to a new module that prevented invalid XML from
getting output
[9] was partially undone in [8] (the userinfo part); the other part was
more database-blowup avoidance

Breaking changes got a bad name earlier because one of them made it kind
of impossible to support both the old and the new behavior at the same
time. This had already been fixed, but the incompatible behavior was
sadly present in 1.12.0rc1 (fixed in the final 1.12.0 release, though),
and now that I know of the issue, I'll think about supporting both old
and new behavior at the same time in future breaking changes.
Ironically, [5] made that kind of support possible in certain situations.

Roan Kattouw (Catrope)

[1]
http://lists.wikimedia.org/pipermail/mediawiki-api/2008-August/000660.html
[2] http://lists.wikimedia.org/pipermail/mediawiki-api/2008-July/000588.html
[3] http://lists.wikimedia.org/pipermail/mediawiki-api/2008-June/000576.html
[4] http://lists.wikimedia.org/pipermail/mediawiki-api/2008-May/000528.html
[5] http://lists.wikimedia.org/pipermail/mediawiki-api/2008-May/000541.html
[6] http://lists.wikimedia.org/pipermail/mediawiki-api/2008-May/000543.html
[7]
http://lists.wikimedia.org/pipermail/mediawiki-api/2008-January/000319.html
[8]
http://lists.wikimedia.org/pipermail/mediawiki-api/2008-January/000311.html
[9]
http://lists.wikimedia.org/pipermail/mediawiki-api/2008-January/000310.html

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Aryeh Gregor]

On Wed, Aug 20, 2008 at 3:08 PM, Roan Kattouw <roan.kattouw@...> wrote:
> About the hooks: most hooks should be in the backend, yes. However,
> extensions like ConfirmEdit need to return certain information (CAPTCHA
> URLs) to the user. There's a UI hook to do that in the UI, and there's
> an API hook to return that information to API users.

What you *should* have is a backend hook that allows cancellation of
an edit, with some way of passing back an error condition that can be
displayed by both the human UI and the API.

> The recurring theme here is that phase4 (if we ever go there) requires a
> rethinking of EditPage.php (and SpecialPreferences.php, BTW).

Sounds like an interesting project . . .

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Lars Aronsson]

Aryeh Gregor wrote:

> On Wed, Aug 20, 2008 at 1:58 AM, Robert Ullmann <rlullmann@...> wrote:
> >
> > http://en.wiktionary.org/wiki/Special:AllPages/Hill


> As far as I can tell, formerly the URL you gave did nothing at all.

This is wrong. It used to list all pages, starting at Hill.  There
were links to the previous and next page of the large listing of
all pages.

> r39427 <http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=39427>
> appears to have allowed subpage syntax to be used for AllPages;

Yes, so it seems if you compare to the immediately previous
version.  But that is the 3rd commit (by aaron) that day.  If you
go back to the older version (revision 36481, June 19), there is a
similar statement isset($par), which calls showChunk() rather than
showPrefixChunk().

The old implementation might have drawbacks, but the new version
is too different in function.



--
  Lars Aronsson (lars@...)
  Aronsson Datateknik - http://aronsson.se

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Jay R. Ashworth]

On Wed, Aug 20, 2008 at 11:58:39AM -0700, Brion Vibber wrote:

> The way it _should_ be working is something like this:
>
> 1) There's a backend ("controller") class for performing edits. This has
> hook points for things like aborting or altering edits (spam checks,
> captcha, etc)
>
> 2) There's a frontend ("view") class for handling the HTML edit form.
> This has hook points for customizing the form output, checking custom
> input, and presenting UI for error conditions ("you hit spam!" or "you
> need to submit this extra form")
>
> 3) There's another frontend ("view") class for handling the API's edit
> interface. This _might_ also have hook points for handling special
> input/output and custom error formatting, though _ideally_ such stuff
> should be able to use existing I/O channels specified in the API (spam
> hit just raises an error conditions; captcha hits have an existing
> channel for saying "show this and respond to it").
>
>
> Currently the EditPage class mixes a fair chunk of backend and UI, as do
> the edit filter hooks for spam blacklisting, CAPTCHAs, etc, so it's a
> bit icky. There's been some refactoring in the course of creating the
> edit API (as there was much refactoring to Special:Userlogin when the
> API's login modules were being created), but it remains incomplete.

So the obvious followup question is: is there a plan to migrate the
front end to *use the API* to talk to the backend (which is the
preferred approach to such things anyway)?

Cheers,
-- jra
--
Jay R. Ashworth                   Baylink                      jra@...
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             [phone]

             Those who cast the vote decide nothing.
             Those who count the vote decide everything.
               -- (Josef Stalin)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Aryeh Gregor]

On Wed, Aug 20, 2008 at 3:19 PM, Lars Aronsson <lars@...> wrote:

> This is wrong. It used to list all pages, starting at Hill.  There
> were links to the previous and next page of the large listing of
> all pages.
>
>. . .
>
> Yes, so it seems if you compare to the immediately previous
> version.  But that is the 3rd commit (by aaron) that day.  If you
> go back to the older version (revision 36481, June 19), there is a
> similar statement isset($par), which calls showChunk() rather than
> showPrefixChunk().
>
> The old implementation might have drawbacks, but the new version
> is too different in function.

Yes, this was all clarified in later messages.  I was wrong, it was a
functional change.  The change was presumably not intended, and Brion
reverted it.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Aryeh Gregor]

On Wed, Aug 20, 2008 at 3:24 PM, Jay R. Ashworth <jra@...> wrote:
> So the obvious followup question is: is there a plan to migrate the
> front end to *use the API* to talk to the backend (which is the
> preferred approach to such things anyway)?

One practical issue with this at present is that nobody who does much
of anything with core does much of anything with the API.  I've barely
looked at it at all.

As a more philosophical thing, there's no reason for the human UI to
call the API.  We should have a back-end, and then two interfaces to
that: one designed for external robots, and one designed for
HTML-viewing humans.  Both of the interfaces should use the internal
PHP interface to speak to the back-end.  The API operates in a format
that's suitable for robots to use, not suitable for internal code to
use.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Aryeh Gregor schreef:

> On Wed, Aug 20, 2008 at 3:24 PM, Jay R. Ashworth <jra@...> wrote:
>  
>> So the obvious followup question is: is there a plan to migrate the
>> front end to *use the API* to talk to the backend (which is the
>> preferred approach to such things anyway)?
>>    
>
> One practical issue with this at present is that nobody who does much
> of anything with core does much of anything with the API.  I've barely
> looked at it at all.
>  

True. Actually, there's a pattern of isolation here. While pretty much
all developers are familiar with the 'core' classes (Title, Article,
Revision, etc.), very few are familiar with isolated ones such as the
parser, the API, the image handling code, the Database abstraction layer
(except for select() and similar functions)
> As a more philosophical thing, there's no reason for the human UI to
> call the API.  We should have a back-end, and then two interfaces to
> that: one designed for external robots, and one designed for
> HTML-viewing humans.  Both of the interfaces should use the internal
> PHP interface to speak to the back-end.  The API operates in a format
> that's suitable for robots to use, not suitable for internal code to
> use.
Simetrical is right here: the UI and the API call the same functions,
and display the results in different ways. That's exactly why there's no
sense in migrating the front end to the API (and that's just forgetting
about the HTTP overhead involved).

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Aryeh Gregor schreef:

> On Wed, Aug 20, 2008 at 3:08 PM, Roan Kattouw <roan.kattouw@...> wrote:
>  
>> About the hooks: most hooks should be in the backend, yes. However,
>> extensions like ConfirmEdit need to return certain information (CAPTCHA
>> URLs) to the user. There's a UI hook to do that in the UI, and there's
>> an API hook to return that information to API users.
>>    
>
> What you *should* have is a backend hook that allows cancellation of
> an edit, with some way of passing back an error condition that can be
> displayed by both the human UI and the API.

Come to think of it, letting the hook pass a message key and letting the
extension add that message key to ApiBase::$messageMap as well seems
like a good idea. Still, we'd be breaking dozens of extensions that way.
I'd like some input from chief developers (you, Brion, etc.) before I do
that.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Aryeh Gregor]

On Wed, Aug 20, 2008 at 4:21 PM, Roan Kattouw <roan.kattouw@...> wrote:
> Come to think of it, letting the hook pass a message key and letting the
> extension add that message key to ApiBase::$messageMap as well seems
> like a good idea. Still, we'd be breaking dozens of extensions that way.

Of course, you introduce a new hook and deprecate the old one (while
still supporting it for now).

> I'd like some input from chief developers (you, Brion, etc.) before I do
> that.

Well, I don't think I qualify as much of a "chief developer".
Especially not to be listed before Brion.  :P

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Aryeh Gregor schreef:
>
> Well, I don't think I qualify as much of a "chief developer".
> Especially not to be listed before Brion.  :P
What I kind of meant is that you provide useful comments on pretty much
everything you see.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Aryeh Gregor]

On Wed, Aug 20, 2008 at 4:41 PM, Roan Kattouw <roan.kattouw@...> wrote:
> Aryeh Gregor schreef:
>>
>> Well, I don't think I qualify as much of a "chief developer".
>> Especially not to be listed before Brion.  :P
> What I kind of meant is that you provide useful comments on pretty much
> everything you see.

Chief pundit, then.  ;)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Jim R. Wilson]

Jay said:
> So the obvious followup question is: is there a plan to migrate the
> front end to *use the API* to talk to the backend (which is the
> preferred approach to such things anyway)?

There are times when utilizing the API programatically could make
extension development much easier.  The last time I looked at the API
certain things were hard coded (such as bot limits - yuck) which made
it tough/impossible to use in certain extension scenarios.  I believe
these have been corrected though, so it's probably a good resource for
certain classes of extensions.

Someone familiar with the core could always construct a proper
$dbr->select() querys, but it would be easier (read: less code) in
some cases to let the API classes handle it.

-- Jim R. Wilson (jimbojw)

On Wed, Aug 20, 2008 at 3:20 PM, Roan Kattouw <roan.kattouw@...> wrote:

> Aryeh Gregor schreef:
>> On Wed, Aug 20, 2008 at 3:24 PM, Jay R. Ashworth <jra@...> wrote:
>>
>>> So the obvious followup question is: is there a plan to migrate the
>>> front end to *use the API* to talk to the backend (which is the
>>> preferred approach to such things anyway)?
>>>
>>
>> One practical issue with this at present is that nobody who does much
>> of anything with core does much of anything with the API.  I've barely
>> looked at it at all.
>>
> True. Actually, there's a pattern of isolation here. While pretty much
> all developers are familiar with the 'core' classes (Title, Article,
> Revision, etc.), very few are familiar with isolated ones such as the
> parser, the API, the image handling code, the Database abstraction layer
> (except for select() and similar functions)
>> As a more philosophical thing, there's no reason for the human UI to
>> call the API.  We should have a back-end, and then two interfaces to
>> that: one designed for external robots, and one designed for
>> HTML-viewing humans.  Both of the interfaces should use the internal
>> PHP interface to speak to the back-end.  The API operates in a format
>> that's suitable for robots to use, not suitable for internal code to
>> use.
> Simetrical is right here: the UI and the API call the same functions,
> and display the results in different ways. That's exactly why there's no
> sense in migrating the front end to the API (and that's just forgetting
> about the HTTP overhead involved).
>
> Roan Kattouw (Catrope)
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@...
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[^demon]

On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson <wilson.jim.r@...> wrote:

> Jay said:
>> So the obvious followup question is: is there a plan to migrate the
>> front end to *use the API* to talk to the backend (which is the
>> preferred approach to such things anyway)?
>
> There are times when utilizing the API programatically could make
> extension development much easier.  The last time I looked at the API
> certain things were hard coded (such as bot limits - yuck) which made
> it tough/impossible to use in certain extension scenarios.  I believe
> these have been corrected though, so it's probably a good resource for
> certain classes of extensions.
>
> Someone familiar with the core could always construct a proper
> $dbr->select() querys, but it would be easier (read: less code) in
> some cases to let the API classes handle it.
>
> -- Jim R. Wilson (jimbojw)
>
> On Wed, Aug 20, 2008 at 3:20 PM, Roan Kattouw <roan.kattouw@...> wrote:
>> Aryeh Gregor schreef:
>>> On Wed, Aug 20, 2008 at 3:24 PM, Jay R. Ashworth <jra@...> wrote:
>>>
>>>> So the obvious followup question is: is there a plan to migrate the
>>>> front end to *use the API* to talk to the backend (which is the
>>>> preferred approach to such things anyway)?
>>>>
>>>
>>> One practical issue with this at present is that nobody who does much
>>> of anything with core does much of anything with the API.  I've barely
>>> looked at it at all.
>>>
>> True. Actually, there's a pattern of isolation here. While pretty much
>> all developers are familiar with the 'core' classes (Title, Article,
>> Revision, etc.), very few are familiar with isolated ones such as the
>> parser, the API, the image handling code, the Database abstraction layer
>> (except for select() and similar functions)
>>> As a more philosophical thing, there's no reason for the human UI to
>>> call the API.  We should have a back-end, and then two interfaces to
>>> that: one designed for external robots, and one designed for
>>> HTML-viewing humans.  Both of the interfaces should use the internal
>>> PHP interface to speak to the back-end.  The API operates in a format
>>> that's suitable for robots to use, not suitable for internal code to
>>> use.
>> Simetrical is right here: the UI and the API call the same functions,
>> and display the results in different ways. That's exactly why there's no
>> sense in migrating the front end to the API (and that's just forgetting
>> about the HTTP overhead involved).
>>
>> Roan Kattouw (Catrope)
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@...
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@...
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

PrefixSearch does it (around line 130).

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Jim R. Wilson schreef:

> Jay said:
>  
>> So the obvious followup question is: is there a plan to migrate the
>> front end to *use the API* to talk to the backend (which is the
>> preferred approach to such things anyway)?
>>    
>
> There are times when utilizing the API programatically could make
> extension development much easier.  The last time I looked at the API
> certain things were hard coded (such as bot limits - yuck) which made
> it tough/impossible to use in certain extension scenarios.  I believe
> these have been corrected though, so it's probably a good resource for
> certain classes of extensions.
>
> Someone familiar with the core could always construct a proper
> $dbr->select() querys, but it would be easier (read: less code) in
> some cases to let the API classes handle it.

Calling the API from within MW (or extensions) can be done using the
FauxRequest class. This also makes the API ignore the maximum limit, so
you can set limit parameters to whatever you like (not to infinity,
however). This feature is documented at [1].

Roan Kattouw (Catrope)

[1] http://www.mediawiki.org/wiki/API:Calling_internally

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Aryeh Gregor]

On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson <wilson.jim.r@...> wrote:

> There are times when utilizing the API programatically could make
> extension development much easier.  The last time I looked at the API
> certain things were hard coded (such as bot limits - yuck) which made
> it tough/impossible to use in certain extension scenarios.  I believe
> these have been corrected though, so it's probably a good resource for
> certain classes of extensions.
>
> Someone familiar with the core could always construct a proper
> $dbr->select() querys, but it would be easier (read: less code) in
> some cases to let the API classes handle it.

That's functionality that the backend should provide, not the API.  At
least IMO.  The API is primarily a bot interface, not a PHP interface.
 Trying to use it as a PHP interface as well will require a lot of
contortions, since there are fundamental differences between the
desirable traits of each type of interface:

* The level of access that bots and scripts can have.  Bots get
carefully limited access, while extensions have unlimited read/write
access.  This means that if the API is primarily targeted at bots, it
will have limited write access, and *very* limited support for
administrative functions that extensions may very well want to invoke.
 For instance, the userrights module was removed on principle, last I
checked, as something that we didn't need the security risks of given
that bots are unlikely to ever need to change user rights.
* The format of access.  Bots use HTTP requests, while extensions use
direct function calls.  HTTP requests are text-only, and consist of
one of a very small number of filenames plus an arbitrary associative
array mapping string parameters to string values.  Function calls
support a rich variety of data types, and consist of any of a
potentially very large number of individual functions plus a small,
fixed ordered list of parameters.  Trying to shoehorn one access
format into another will require contortions like FauxRequest.
* The cost of access.  HTTP requests have very high overhead -- set up
network connection, pass request through a long chain of servers and
processes, send result back -- usually on the order of a hundred
milliseconds or more.  Function calls have very low overhead, without
even a context switch: likely well under a microsecond.  Moreover,
HTTP requests are stateless, while a function-call-based interface can
maintain extremely rich state.  These push the format and nature of a
bot API in a very different direction from that of an extension API.
A bot API will tend to encourage a small number of elaborate requests,
because the state must be built on every request.  A good extension
API, on the other hand, allows many small function calls, reusing
state (such as already-initialized objects) as often as possible, with
each function doing one thing.  Again, these cannot be cleanly
reconciled.

Although I'm not an extension author, and you are, I don't *think* you
want to use the API, now or ever.  I think what you want is a clean
separation between backend and frontend.  You should then be able to
call the backend functions directly, and they'll provide you with
clean functionality like "perform an edit by this User object to this
section number of this Article object with this text, with(out) usual
permission checks, returning an easily-parsed array of errors and
warnings if any occur".

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Jay R. Ashworth]

On Wed, Aug 20, 2008 at 04:01:14PM -0400, Aryeh Gregor wrote:
> On Wed, Aug 20, 2008 at 3:24 PM, Jay R. Ashworth <jra@...> wrote:
> > So the obvious followup question is: is there a plan to migrate the
> > front end to *use the API* to talk to the backend (which is the
> > preferred approach to such things anyway)?
>
> As a more philosophical thing, there's no reason for the human UI to
> call the API.

Sure there is.  Jon Bentley is wrong?

>                 We should have a back-end, and then two interfaces to
> that: one designed for external robots, and one designed for
> HTML-viewing humans.  Both of the interfaces should use the internal
> PHP interface to speak to the back-end.  The API operates in a format
> that's suitable for robots to use, not suitable for internal code to
> use.

I think we're bandying semantics.  There should be one interface to the
core, which provides all the functionality necessary, and one of the
clients to that interface should be the tradtional front end.

It's a design pattern that is well tested and proven... and means you
never have to hear "why can't I access that function from the front
end" again.

It also makes for a cleaner separation of powers from the UI to the
core.

Cheers,
-- jra
--
Jay R. Ashworth                   Baylink                      jra@...
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             [phone]

             Those who cast the vote decide nothing.
             Those who count the vote decide everything.
               -- (Josef Stalin)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l