I disagree with only. Extensions dont just query the db and sometimes
extensions need to do things we cant put in a web api. But it would be *c*ool
if using the api internally was encouraged.
(Keep in mind action=parse and action=edit of the api is unsafe to call
internally at some points in the code)
-bawolff
On 2013-02-11 9:47 AM, "Yuri Astrakhan" <yuriastrakhan(a)gmail.com> wrote:
I have a blasphemous proposal... extensions should
only use the public API
via FauxRequest objects. The public API interface has been very stable, and
it gives MW core devs much more flexibility with changing the innards of
the system...
On Mon, Feb 11, 2013 at 8:36 AM, bawolff <bawolff+wn(a)gmail.com> wrote:
I don't think she means what we call the api
- but more methods random
extensions are likely to use.
We could start documenting certain stable methods with a special code
comment ( say @stable) which would mean something like this method will
not
be removed, and if the need arises we'll
remove the @stable and wait 2
versions before removing the method. Key candidates for this would
include
title::newFromText, parser::recursiveTagParse,
etc. Ideally one would
wait
for the method to stand the test of time before
tagging.
I
am sure WMF developers are facing >similar issues especially
I don't think that's the case. It used to be the responsibility of the
person making the breaking change to fix all callers in the wikimedia
extension repo. Im not sure if that's still the case but nonetheless I do
not feel this is a significant problem for deployed extensions.(im sure
someone will correct me if im wrong)
-bawolff
On 2013-02-11 9: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