Page MenuHomePhabricator

Be explicit about what ext api exports
Closed, ResolvedPublic

Description

@ssastry says,

This is a tangential comment ... but I have been watching the ext api exports expanding slowly ... I am mildly worried that, without some attention, a lot of parsoid code will get exposed through these interfaces and extensions will start doing obscure things through whatever internals they can get their grubby hands on ... i.e. one complaint i have about php parser hooks is that they expose parsing internals of the php parser that can't be duplicated elsewhere (ex: parsoid). We don't that happening here now. So, we need to take a step back at some point soon and look at the abstract interface we want to expose to extensions and think about how to make sure they have just that and nothing more.

in https://gerrit.wikimedia.org/r/#/c/281076/10/lib/config/extapi.js

Event Timeline

Arlolra triaged this task as Medium priority.Jan 24 2017, 5:13 AM

To the extent we make a special extension API, it would be great if it could mirror either the client-side JS api (ie, https://www.mediawiki.org/wiki/ResourceLoader/Modules#mediawiki.api ) or some PHP API wherever possible, so we aren't forcing extension authors to learn *yet another* way of doing "the same thing".

Change 420118 had a related patch set uploaded (by Subramanya Sastry; owner: Subramanya Sastry):
[mediawiki/services/parsoid@master] Updated extension interface + native Parsoid impl of Poem

https://gerrit.wikimedia.org/r/420118

Change 420118 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Updated extension interface + native Parsoid impl of Poem

https://gerrit.wikimedia.org/r/420118

Arlolra claimed this task.
Arlolra reassigned this task from Arlolra to ssastry.