I'm excited to see this all moving forward! I think there are potential
boons for regular mobile AND zero experiences in here. Responses inline
below.
On Thu, May 30, 2013 at 10:16 AM, Yuri Astrakhan
<yastrakhan(a)wikimedia.org>wrote;wrote:
*== Proposals ==*
In order to reduce Zero-caused fragmentation, we propose to shrink from one
bucket per carrier (X-CS) to three general buckets:
* smart phones bucket -- banner and site modifications are done on the
client in javascript
For smart devices (more than just phones!), is there any reason you'd need
serve different HTML than what is already being served by MobileFrontend?
Note that there would need to be one bucket for HTML with images, another
for without (as currently is the case for smartphones accessing
MobileFrontend). Are there 'site modifications' that Zero needs to do that
are different from MobileFrontend?
* feature phones -- HTML only, the banner is inserted
by the ESI
** for carriers with free images
** for carriers without free images
What about including ESI tags for banners for smart devices as well as
feature phones, then either use ESI to insert the banner for both device
types or, alternatively, for smart devices don't let Varnish populate the
ESI chunk and instead use JS to replace the ESI tags with the banner? That
way we can still serve the same HTML for smart phones and feature phones
with images (one less thing for which to vary the cache).
Are there carrier-specific things that would result in different HTML for
devices that do not support JS, or can you get away with providing the same
non-js experience for Zero as MobileFrontend (aside from the
banner, presumably handled by ESI)? If not currently, do you think its
feasible to do that (eg make carrier-variable links get handled via special
pages so we can always rely on the same URIs)? Again, it would be nice if
we could just rely on the same HTML to further reduce cache variance. It
would be cool if MobileFrontend and Zero shared buckets and they were
limited to:
* HTML + images
* HTML - images
* WAP
Out of curiosity, is there WAP support in Zero? I noticed some comments
like '# WAP' in the varnish acls for Zero, so I presume so. Is the Zero WAP
experience different than the MobileFrontend WAP experience?
Since we improved MobileFrontend to no longer vary the cache on X-Device,
I've been surprised to not see a significant increase in our cache hit
ratio (which warrants further investigation but that's another email). Are
there ways we can do a deeper analysis of the state of the varnish cache to
determine just how fragmented it is, why, and how much of a problem it
actually is? I believe I've asked this before and was met with a response
of 'not really' - but maybe things have changed now, or others on this list
have different insight. I think we've mostly approached the issue with a
lot more assumption than informed analysis, and if possible I think it
would be good to change that.
*=== Varnish logic ===*
* Parse User-Agent to distinguish between desktop / mobile / feature phone:
X-Device-Type=desktop|mobile|legacy
What is 'legacy'? Why would you ever set X-Device-Type to 'desktop'? We
already have decent device detection at the Varnish layer for
MobileFrontend, however the devices aren't bucketed quite the way I think
you'll need - but that should be straightforward to add into or along side
the existing device detection.
...
> *=== ZERO vs M ===*
...
> In general, we should manipulate image
links in M for carriers who don't
> allow them, and always redirect ZERO to M unless M is not whitelisted, in
> which case convince carrier to change their whitelist.
>
What do you mean by 'manipulate image links in M'? Do you mean just don't
display images (like currently happens) when images are disabled (X-Images:
No)?
I dont think this should be a big deal especially if we can determine the
value of X-Images for specific carriers at the Varnish level rather than at
the application level - unless you're suggesting that something else needs
to happen with image links.
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687