Max,
For regular page views we split it into two requests: one for lead section
and another for the remaining sections.
As a general rule of thumb we want to put only the information that is
needed to display above the fold (section 0, lead image URL, Wikidata
description, ...), plus maybe some minor metadata fields that help us with
housekeeping.
The gallery data for should go into the second request.
As far as housekeeping goes, I think it would be great to have the revision
ID and some hash for the things outside the pure pagedata (gallery items,
...)
so we could determine after the first request if we could skip the second
request because we already have that as a saved page or in a cache.
Ideally, those would go into an ETag, and the client uses an If-None-Match
header the next time we request it, so that in the case we already have the
data there wouldn't be a payload in the response, just the header.
Bernd
On Thu, Feb 5, 2015 at 9:59 PM, Monte Hurd <mhurd(a)wikimedia.org> wrote:
Saving pages is not the primary use case for the image
meta data portion -
users tapping on an image and not having to wait for another server round
trip to determine the high res url and meta data is the primary use case.
Having all this data as part of one request means image taps can be much
lower latency from the user's perspective. The panel can pop up immediately
with meta data overlay over the already downloaded low res image and can
immediately begin lazy loading the high res version. It will seem much more
responsive, which is really important.
As a side benefit, saving page data for offline access also becomes
easier, but users tap on images (I think) more than they save pages.
On Feb 5, 2015, at 1:40 PM, Max Semenik <maxsem.wiki(a)gmail.com> wrote:
Saving a page for offline is not that speed sensitive, however, serving
this information as part of normal page views would definitely impact
overall latency.
On Thu, Feb 5, 2015 at 1:24 PM, Dan Garry <dgarry(a)wikimedia.org> wrote:
On 5 February 2015 at 13:20, Max Semenik
<maxsem.wiki(a)gmail.com> wrote:
Wouldn't that bloat the response size?
The rationale for including this is because that way the image viewer
will work even if you've not tapped on any of the images. This is pretty
important functionality that doesn't work offline right now, even if you
save the page for offline reading.
That said, we may want to punt this until after the MVP as being possibly
outside of scope.
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l