Simetrical+wikilist at gmail
Aug 21, 2008, 2:10 PM
Post #7 of 24
(1319 views)
Permalink
|
|
Re: Will the frontend ever use the API, itself?
[In reply to]
|
|
On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson <wilson.jim.r [at] gmail> 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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
