Maria: see http://www.mediawiki.org/wiki/API:Calling_internally for info on calling the api internally.
However thinking about it the interface is not really well designed for calling internally. One would expect a high level internal api would be returning title objects. One would not expect such an api to require you to have fake request objects. There is no documentation about which api methods are safe to call from a parser hook extension. There are several that are not.
Last of all, it doesnt really solve the problem maria brought up. The api called internally can really only act as a high level way to query the db. The db related methods are some of the most stable methods in all of mediawiki. Using the api might isolate you from certain db schema change But realistically non backwards compatible db changes are exceedingly rare.
-bawolff
On 2013-02-11 10:01 AM, "Maria Miteva" mariya.miteva@gmail.com wrote:
Yes, precisely. Is there an accepted way to call it, so I don't confuse people every time I talk about it ?
Yuri, I am working on getting some concrete examples.
Mariya
On Mon, Feb 11, 2013 at 3:24 PM, Chad innocentkiller@gmail.com wrote:
I believe Mariya is talking about the internal APIs available to extensions, (eg: User, Title, EditPage, so forth), not the public API.
Yay, acronyms!
-Chad
On Mon, Feb 11, 2013 at 8:14 AM, Yuri Astrakhan <yuriastrakhan@gmail.com
wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality
(new
actions, new query submodules, new parameters), but that shouldn't
have
significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the
extensions
should not be affected) in 1.21, such as the introduction of
versioning,
further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF
internship in
the last few weeks and one the main concerns they express is the
lack of
stability in the PHP classes MediaWiki exposes from version to
version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility
from
version to version becoming a problem. Solving the problem would
probably
result in the development of more extensions, easier maintenance,
less
hacks to core and more users upgrading to the latest MediaWiki
version.
I
am sure WMF developers are facing similar issues especially with
projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki
carries,
is it possible to have a (relatively) stable set of PHP classes
defined,
with a pledge not to change them in the next X releases or at least
with
some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in
MediaWiki
code? Does it require restructuring a lot of the current core code?
Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l