-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mediawiki MobileView API deprecated, Mobile Content Service deprecated too, migrate to WMF-recommended solution #5165
Comments
Hi @nicolas-raoul Please assign to me ,I will work on this. |
@awanishyadav967 It is yours, thanks! Please let us know about your progress or share your findings every few days. |
@nicolas-raoul The issue seems to be unassigned. Could you please assign the issue to me? |
@kartikaykaushik14 Of course, thanks! |
@nicolas-raoul I was going through the mobile content service API Documentation and just last week they posted a decommissioning notice and asked to migrate to Page Content Service - Reference |
@kartikaykaushik14 Thanks for the hint! It looks like Parsoid is JavaScript, it might be usable via WebViews. One could argue that we should follow what the Android Wikipedia app is doing, which is apparently the Page Content Service ("PCS"), but a counter-argument would be that it is unstable. The first task would be to list our different use cases of the API, to see how well these use cases are covered by Parsoid and PCS, possibly via a tiny prototype app. |
I was trying to analyze which REST endpoints are impacted by the deprecation of MobileView API and their possible alternatives from Page Content Service.
But, the endpoints are currently unstable as per current documentation. |
Even these endpoints in Page Content Service are now deprecated. However, mobile-html endpoint uses Parsoid HTML. But it's currently in the experimental phase. |
Are there any updates on Mobileview API replacement? Also, what is expected to break if MCS API is disabled on server side if commons app doesn't have it replaced yet? |
@kartikaykaushik14 Are you still working on this issue? If so, could you update your progress on this? |
I think that could be a GSoC project. If too easy, this plus #3083. |
@sivaraam Sorry I couldn't continue further on the issue. Will be a little free from work in the upcoming weeks. But feel free to reassign this issue or make it a part of next GSoC. |
No issues @kartikaykaushik14 ! Kindly feel free to work on this if you're able to find time. At a later stage, if there's anything that's left to be converged, we could convert that remaining part into a GSoC project. |
We pinged the WMF team for some inputs on how to go about with the migration. @dbrant kindly took a look at our code and provided the following clarification:
So, I think the only thing left to do here is to identify the stale portions of code and remove them :-) |
@kartikaykaushik14 Are you planning to work on this? :-) |
I've spent some time digging through the data-client module to remove "dead code" that appears to be unused. If you're curious, it's on a branch that you can browse. If we're looking for a migration path to a different API, I hope you find the investigation useful! |
@psh Wonderful! Feel free to send a pull repuest. 🙂 |
From what I have seen, now that dead code is pretty much gone, is that we are using 5 things from the
In terms of size, "thanks" and "notifications" are probably the easiest and mirrors other self-contained API calls we make in the app as far as work goes. Something like Login already exists in the app, so we'd be moving 4 classes over from the data client. The CSRF client makes use of it, so maybe those have to move together. 🤔 Seems like a logical grouping to me. If we leave the data model base classes for last, then (I think) each of the other steps is self-contained and you wont end up with strange circular dependencies of the data client module depending on the main app. |
Sounds like a good plan. Thanks a lot for taking the time to help with the clean up of the data-client module! 🙂 |
OK, quick "state of the union" update for those who are interested -
So, what's left?
|
Wonderful! Thanks for all of this great work! 🙂 |
Quoting from earlier in this issue -
With the most recent commit (thanks to @nicolas-raoul for his patience as it was pretty huge) the "data-client" module is gone. The small portion of code from it that we were using is incorporated into the commons app proper. I believe that wraps up the work we wanted to do here, unless there are other API related cleanup operations to address? Maybe we can gather our thoughts in this thread, spin off separate issues if we spot things we want to do, and close this one? |
I suppose so too. Thanks a lot for taking care of this in review friendly part-by-part fashion, @psh! 🙂
I can't recollect any API cleanup similar to this one that we've left out. On a tangent, there are a few API related issues such as #5244 / #3179 that are still open in our issue tracker. Feel free to take a stab at them if you're interested. If you're looking for other kind of issues, feel free to elaborate. We could identify relevant ones.
Most certainly 👍🏼 |
Thanks a lot Paul for this fantastic work! 🙂 |
https://phabricator.wikimedia.org/T210808
https://www.mediawiki.org/wiki/Mobile_Content_Service
The text was updated successfully, but these errors were encountered: