[11:39:34] coreyfloyd: i have no idea right now.. it's been a long time since i looked at that data but we do log it somewhere. [11:39:43] I'd expect it to be more in the thousands then millions though [13:39:54] jdlrobson: ok, that's probably enough to ball park [15:04:07] android standup reets_afk? :D [15:29:36] coreyfloyd: are Android users always required to log in? [15:29:56] tgr: no [15:29:58] I'm trying to figure out how to get an absoulte request count projection for reading lists [15:30:08] tgr: but they will be required to for this feature [15:30:45] tgr: I used the number based on existing reading list functionality - assuming that all users will log in [15:31:05] the existing feature is available whether logged in or not, right? [15:31:19] tgr: it should be good for the upper limit, but yeah some users may not opt in to syncing [15:31:58] tgr: yes. That's why it is an upper bound. But the feature is highly requested and will be highly promoted [15:33:15] tgr: so I don't think you can use existing log in stats in a meaningful way. Currently users have no reason to log in (editing isn't really a common use case). This is the first reading feature that really will be pushing users to authenticate [15:47:23] tgr: I updated the doc with some more projections including a small web beta [16:23:47] coreyfloyd: if we expect that promoting reading lists will result in magnitudes more readers being logged in, that's probably worth a conversation of its own with ops [16:24:04] they cannot be served by Varnish for pageviews etc [16:24:17] but I imagine that's some future quarter [16:26:13] tgr: yeah its about 10%… which according to the projections is about 1M users [16:26:19] mdholloway: here's another option from google: https://developer.android.com/reference/android/webkit/WebViewDatabase.html#setHttpAuthUsernamePassword(java.lang.String, java.lang.String, java.lang.String, java.lang.String) . it might still be plain text though (test with sqlite3 /data/data/org.wikipedia.dev/app_webview/Web\ Data .dump [16:26:51] tgr: Does RESTBase return pages differently for authenticated users? [16:27:02] I mean the parsoid endpoint… [16:27:29] Not sure if they do it there OR if they handle the authentication in another API call… [16:28:10] I don't think it affects RESTBase [16:28:33] tgr: ok if not then it seems like it doesn’t matter [16:28:34] they don't care about authentication, and if the headers are properly set Varnish will know that and cache everything [16:28:45] kk [16:28:53] tgr: all app clients will be on RESTbase [16:28:59] we don't use parsoid for page views yet, though [16:29:26] app traffic is a small fraction anyway [16:29:49] I'm thinking about web users starting to log in en masse because of the new feature [16:30:09] if we expect that to happen, that might have implications beyond the reading list service [16:31:06] tgr: gotcha…yeah that may be important. Depending on if Reading lists are implemented in MobileFrontend or only in the new Web App [16:32:03] Byt yeah good one to file regardless… its something we should make sure we are prepared or [16:32:04] for [16:33:00] bearND: tar I updated the Kanban board to what I THINK is up to date on your status. Please feel free to correct it [16:33:06] tgr: ^ [16:33:58] coreyfloyd: mine looks good to me. Thanks! [16:36:53] tgr: logged in Android app users are still served the same content as not-logged in users. [16:39:58] so they get the benefit of caching. The editable flag is combined with information about the logged in group memberships to actually determine if a user can edit a page. There are no gadgets or user-specific CSS/JS in the Android app. [16:46:36] niedzielski: interesting, thanks, i'll check that out! [16:46:57] bearND: yeah, but the apps are no big deal from an ops perspective anyway, they are like 1% of the traffic [17:10:44] tgr: FYI I added some more information to the doc today under Background, Privacy, Usage projections, and Dependencies [17:38:55] mhurd: so it looks like the extra-wide math equation CSS will be fixed in MobileFrontend \o/ [17:40:03] oh awesome!!! :) [17:40:47] mhurd: do you have a quick example of an article with an extra-wide image (that is not an equation)? [17:43:04] iirc the "counties of england" article has a couple - and they have image map or div overlays so we actually don't want to change their size or they get out of sync with their link coordinates. [17:59:59] mdholloway: dbrant niedzielski : Are you cool with https://gerrit.wikimedia.org/r/#/c/352189/? [18:01:15] dbrant: niedzielski: sure, i can +2 if it's cool w/ everyone else [18:01:24] +1 [18:01:51] (checking now) [18:03:27] bearND: looks fine. thanks [18:15:26] niedzielski-afk: dbrant: i'm testing wikipedia zero to update the client and the notifications are out of control... [18:15:37] i have a hunch it has to do with the cache update [18:16:01] occasionally an X-CS header isn't getting passed through or something [18:16:50] i'll write it up [18:17:06] mdholloway: hmm... idea: the Zero interceptor should only care about the headers if the response is from the network, not cache. [18:17:52] dbrant: true. if we can identify responses from cache, we should disregard those. [18:26:10] dbrant: actually, it's even weirder than that: a zero-off notification is triggered by navigating to the settings activity. [18:26:43] i'm pretty sure there's no network activity occurring there. except, maybe EventLogging? though not as far as i can remember. [18:27:17] yep, eventlogging. [18:27:18] huh. [18:28:12] mdholloway: in the Dev flavor, eventlogging gets sent to beta labs, which does not respect Zero headers. Do you get a thrash of zero notifications if you try the Production flavor? [18:29:54] dbrant: ah, no. not on prod or beta. [18:29:59] sorry about the false alarm [18:30:03] that's expected, then. [18:30:22] but still, the Zero interceptor shouldn't really care about cache responses. [18:30:24] yep. i was a little more concerned because we got a negative review about zero thrashing recently [18:31:01] maybe the person is using the alpha build, or is just sensitive to a normal amount of notifications. [18:34:40] dbrant: looks like the zero interceptor is checking network responses only, so we should be good there: https://github.com/wikimedia/apps-android-wikipedia/blob/master/app/src/main/java/org/wikipedia/dataclient/okhttp/WikipediaZeroResponseInterceptor.java#L22 [18:34:54] well alright! [18:47:35] mdholloway: thanks for reporting! i'm sorry but i left a comment about this behavior in 93e6bd576 [18:47:53] it would have been better placed in the interceptor itself [18:49:25] niedzielski: ah :) thanks for the pointer, i missed that one [19:37:46] dr0ptp4kt coreyfloyd: sorry, hangout issues [19:38:03] dr0ptp4kt coreyfloyd: trying to get back in [19:45:41] mdholloway: one more: https://gerrit.wikimedia.org/r/#/c/353008/. Thanks! [19:48:47] bearND: looking [20:09:26] mdholloway: Thanks. Any issues found? [20:10:33] bearND: not really. merging now. it would be nice to use a wildcard selector instead of having to do separate querySelectorAll calls for each element type, but that doesn't seem to work [20:14:57] mdholloway: I think it's possible (using * as the selector). Just not sure if we want to really include tables and figures.