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" <yuriastrak...@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...@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" <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
