On Mon, Nov 4, 2013 at 4:50 AM, Mark A. Hershberger mah@nichework.com wrote:
Hrm... I should probably go ask them about that. But I'm curious about your perspective and to see if we have any information on the bandwidth available to various users.
There is some, but not enough for us to know in advance what sort of impact this will have. But Aaron Hafaker and I are working on it, and we are going to be rigorous about measuring it, and we will report back.
On Mon, Nov 4, 2013 at 9:03 AM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Mon, Nov 4, 2013 at 11:13 AM, Jon Robson jdlrobson@gmail.com wrote:
I'm looking forward to seeing how this plays out. The only downside I can so far see is that the amount of browser storage available varies drastically [1] and I wonder whether this will cause upsets for those browsers with extremely strict limits.
Or, for that matter, if it will fill up the allowed storage so user scripts and gadgets can't make effective use of it.
You can find out the current byte size of the module store by evaluating "mw.loader.inspect('store')" in a JavaScript console on the wikis on which it is enabled (test, test2, beta cluster, and twn). testwiki's JavaScript payload is usually a superset of the modules deployed on various wikis, and the size of a fully warm module cache is 710 kB. This should leave plenty of room on all but the most restrictive platforms. However, if it does end up soaking up so much space that it compromises the functionality of other scripts, I think we could simply modify the implementation to make it honor some soft limit, possibly one that is determined in reference to the user agent.
On Tue, Nov 5, 2013 at 1:00 AM, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:
I found a usability problem with some versions of the webkit/chrome inspector for localStorage due to this, it is being tracked here:
Thank you for doing that.
--- Ori Livneh