On 10/15/2015 08:52 PM, Bernd Sitzmann wrote:
As part of moving the Mobile Content Service to use Parsoid instead of
action=mobileview[1] I've ran into several missing features which make it
significantly harder for the Mobile Content Service to use Parsoid, while
providing the same functionality as before[2]:
(1) Parsoid does not follow redirects.
Automatic redirects (caused by page moves) will be (somewhat) handled by RB
infrastructure[3] soon, this does not yet cover manual redirects. Even then
it sounds like it would result in a 301 which the service would have to
deal with.
Manually (Community-) added redirects would have to be dealt differently by
parsing the Parsoid payload.
<link rel="mw:PageProp/redirect" href="..."/>
While we could overcome the redirect issues by following those redirects I
think this should be a Parsoid feature.
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).
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.
(2) <img> doesn't have srcset attributes with higher-res thumbnails. So,
image widening in the Android app wouldn't be feasible. While there is talk
about Parsoid potentially addressing this in the future I don't know the
timeline for this and don't see a good workaround for this from the service
side.
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.
(3) No direct access to the spokenWikipedia audio files (from the
SpokenWikipedia templates).
A more general version of this is:
No direct access to transcoded audio / video files. [4] is the task in
question. This task is delayed in favor of adding <section> tags.
Theoretically the service could work around this by making another MW API
call. I just have not found it and I don't know how this is done for
action=mobileview. If anyone has a solution that actually works please let
me know. Exposing the spoken version of articles is one of our quarterly
goals.[5][6]
Also see https://phabricator.wikimedia.org/T113066#1667241 and
https://phabricator.wikimedia.org/T114072#1704458 for context about the
goal setting around these requirements.
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 ?).
Given all the above, I would appreciate some more clarity why this lack
of immediate support for this makes this a -2 blocker ... my question
should be read as follows: we try to divide our time between
maintenance, supporting clients with whatever is blocking them in their
use of Parsoid, and in forging ahead with other work around templates
and wikitext. There are a lot of competing priorities / requests (and
from multiple teams) on the parsing team's limited engineering
resources. Adding multimedia support is a good thing and it helps
everyone, and so we will undertake that soon anyway. But, a -2 blocker
from mobile apps seems like a very strong signal. So, a little bit more
interpretation and context around that will help us with our prioritization.
Thanks,
Subbu.
I think we should postpone the move to Parsoid until we have at least a
solution for issues #2 and #3. Subsequently, I've -2'd my patch[2] to move
the service to Parsoid.
Thanks,
Bernd
[1] https://phabricator.wikimedia.org/T108777
[2] https://gerrit.wikimedia.org/r/#/c/246100/
[3] https://github.com/wikimedia/restbase/pull/365
[4] https://phabricator.wikimedia.org/T64270
[5] https://phabricator.wikimedia.org/tag/mobile-app-goals/
[6] https://phabricator.wikimedia.org/T114525
_______________________________________________
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
