Hi Subbu,
Parsoid is a wt <-> html conversion service and the output for a page (even
those with redirects) should reflect what is on that page. This is important, for example, if you want to edit the page with the redirect and change it to something else. However, there could be a version where Parsoid follows the redirect internally and generates the HTML when provided with an explicit API flag to do so (there could be a discussion about what should be the default mode, but there would have to be 2 different modes for sure).
Yes, 2 different modes or endpoints would be fine with me. I would argue that following redirects should have been the default behavior, but I concede that this is harder to do now as to not break your current users.
In any case, given that Parsoid's HTML clients usually talk through RESTBase rather than with Parsoid directly, this optional API flag would also have to be supported in RESTBase, and could potentially follow the redirects on behalf of the clients.
I'm not sure why RESTBase would have to support this. I think there should be also some indication in Parsoid's output to indicate that a redirect happened and from where, like it's done on the website.
(2) <img> srcset:
This is not a huge undertaking, but the reason it hasn't been done is
because of reasons in https://phabricator.wikimedia.org/T88827 .. but, we talked about this a bit at our offsite couple days back, and we are leaning towards going ahead with it. Once we have a firm grasp on that reasoning, this shouldn't take more than a week to get this all done, if that. So, this can be unblocked fairly quickly.
This is great. This is my main concern right now since that would be hardest to work around.
(3) No direct access to the spokenWikipedia audio files [...]
It looks like Mobile Apps and Mobile Web have different priority
requirements from Parsoid here. Looking at https://en.wikipedia.org/wiki/Wikipedia:Spoken_articles, I also see that there are only 1243 spoken wikipedia articles (that are probably not all the latest version of these articles). It also doesn't look like the video player works currently in mobile web or in mobile apps (except maybe Android ?).
Yes, the web team is at a different stage of using RESTBase and/or Parsoid than the Android app team. The Android app team wants to use RESTBase (ideally in combination with Parsoid) for the Android beta app in a couple of weeks. The web team is in more experimental stages during Q2. Yes, the Android app plays videos, too (from the Gallery). Since the spokenWikipedia usage is not so high I'd be willing to make another MW API call to get what we need (even though that would be a step back). It would be great if anyone had a better solution to get the URLs to the audio files directly. I don't want to have to load all sections of mobileview just to get a little piece of information out of that.
But, a -2 blocker from mobile apps seems like a very strong signal.
The -2 is for my own patch, just indicating that this patch is not ready to merged. Once the blockers are resolved (either by Parsoid or a workaround) then this -2 will be removed, of course. It's just a temporary thing. We're still hopeful to be using Parsoid in the future.
From my perspective, the top priority of things to fix in Parsoid out of
those three would be the missing srcset attributes.
Thanks, Bernd