Hi Max & Mobile folks!
On 07/26/2014 01:26 AM, Max Semenik wrote:
I'd like to hear your thoughts on how it can be
changed, can its interface be simplified (e.g. [1]), how fast do we want it
to perform, what do we expect from Parsoid migration.
The main benefit from using Parsoid HTML is that it enables you to more
easily re-style or massage the content with a stable HTML spec [DOMSpec]. As
an example, it is straightforward to identify transclusion expansions in
Parsoid HTML, which lets you pull out this content or massage it to better
display on mobile. The full HTML for each revision will be available as
static HTML.
The other area of interest to you should be the upcoming storage service &
REST API. This infrastructure will help to provide a low-latency REST
interface backed by storage. First performance data shows a request latency
in the single-digit ms area at request rates of around 2k req/s, using a
single CPU thread. There will also be a mechanism to pre-generate custom
content after an edit, so that a later request will typically just retrieve
a stored blob.
On Tue, Jul 29, 2014 at 10:32 AM, Brion Vibber
<bvibber(a)wikimedia.org
<mailto:bvibber@wikimedia.org>> wrote:
On a slow connection pulling down multiple
sections in one blob is tricky
-- JSON decoders don't normally stream so we end
up being pretty slow with
that "second section and beyond" request.
I guess it would make sense to benchmark different solutions, including
loading the full HTML & letting it render progressively. Images etc could
perhaps be disabled by default outside the first section, and then uncovered
/ re-enabled progressively by JS.
I would love
to be able to include action=query stuff along with a mobile
view request, such as
grabbing the current user and site metadata.
Sigh, without core support we can only do one-offs to return select parts in
mobileview. Is there anything particular that you want? Also, it's not a
browser environment and you can actually make a couple reqests in parallel
to e.g. decouple siteinfo retrieval.
There will also be SPDY support in the foreseeable future, which will
further cheapen individual requests. Ops currently has this scheduled for
Q2, and I'll push for the REST API to enable it from the start. Yuvi also
has been running Nginx with SPDY for the labs proxy for a long time now.
Exposing CSS
and scripting modules for extensions used would be nice.
Alternately we can try to
retool things intoself contained embeddable I frames.
This is something worth investigating (as well as returning mw.config values
related to page being retrieved), however I suspect that there will be a few
wwonderful obstacles to work around, as a lot of extensions just add their
modules/variables to OutpuPage in hooks scarily close to page display,
making a lot of assumptions that are not true for API page views.
This is somewhat related to
https://bugzilla.wikimedia.org/show_bug.cgi?id=67540. We plan to expose this
metadata through the REST API, so that clients can load the right modules
for the page content.
Gabriel
[DOMSpec]:
https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec