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(a)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(a)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(a)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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l