On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson wilson.jim.r@gmail.com 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".