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.mit...@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 <innocentkil...@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 <yuriastrak...@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.mit...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
