[00:29:20] gilles: thanks for letting us know, i'll create a ticket [00:40:10] gilles, bmansurov: that's a template fail http://en.wikipedia.beta.wmflabs.org/wiki/Animal [00:42:08] MaxSem: i see [09:00:44] hi [09:00:47] morning y'all [09:01:13] hey joakino [09:01:25] morning phuedx [09:01:43] phuedx: been looking at the alpha ticket, had a question [09:01:49] shoot [09:03:13] phuedx: imagine we want to keep the wikidata infobox active, but only so in beta-labs and in "beta" mode. what would we do? Create a feature flag that defaults to false, and change the deployment config for beta-labs to enable it? [09:03:47] I haven't heard jdl chime in on the wikidata infobox, I thought he would [09:07:41] joakino: yes [09:07:44] exactly that [09:08:08] eventually i'd like all of our features flagged and the config shunted down using the ResourceLoaderGetConfigVars hook [09:08:32] phuedx: aha ok [09:09:21] joakino: what do you think? [09:09:35] phuedx: sounds good to me [09:09:53] i'm still reading the thread [09:10:02] i'd like code to be on the cluster as soon as possible but disabled by default [09:10:08] all of the alpha tickets? [09:10:24] do chime in -- your opinion's super useful [09:10:25] phuedx: i'd like to feature flag the wikidata infobox and keep it visible somewhere, I know we've shown it a few times to illustrate a point [09:10:48] ^ copypasta to phab ;) [09:11:48] phuedx: yep, sounds good over all, I'm going to suggest feature flagging the beta features too. We should be able to turn them off at will [09:11:58] +1 million [09:12:11] /all/ features should be flagged [09:12:14] ideally [09:12:25] and they should be easy to remove if they are not wanted on stable [09:12:31] i mean, they are technically [09:12:37] we could just turn off the mobile site ;) [09:12:48] sounds good haha [09:13:31] joakino: there might be some work to codify the "feature lifecycle" when the backend is processing [09:13:35] wait… [09:15:00] interface FooFeature { [09:15:00] function isEnabled( MobileContext $context ); [09:15:00] function getHeadModules(); [09:15:00] function getModules(); [09:15:00] [09:15:01] /* ... */ [09:15:01] } [09:15:22] isEnabled would mostly read from config thinking about it [09:15:51] might be a nice way to codify what features we have too [09:17:54] who doesn't like classes? [09:18:44] i love 'em [09:18:48] more classes please [09:20:15] phuedx: btw great talk https://www.youtube.com/watch?v=o9pEzgHorH0 [09:20:42] hah [09:39:27] joakino: i'm pretty sure that jdl chimed in on the infobox -- but more of a "boo, but ok" sorta way [09:40:24] phuedx: yeh i just saw it, commented there as well [12:12:32] gonna go for lunch [13:11:33] back [15:17:15] phuedx: so, there's a "page_image" pageprop? [15:17:19] did you know about this? [15:40:19] yup [15:40:28] it has a couple of limitations [15:40:40] which are fixed in mobileview but haven't been upstreamed [15:40:55] sorry, worked around in mobileview [15:42:24] bgerstle: ^ [15:42:38] woah -- thunderstorms outside [15:43:00] phuedx: k. wonder why we're not even using it in the apps [15:43:07] instead of the "grab the first image or thumbnail" [15:43:16] oh no, i think that's what it does [15:43:27] . . . [15:43:31] but you can set it, right? [15:45:43] yarrrp -- sorry was thinking about something else [15:46:34] so it defaults to the heuristic, i assume [15:46:37] which is sane [15:46:41] desirable, perhaps [15:47:49] something to keep in mind if/when this problem ever gets solved [15:48:02] bgerstle: sec, finding you a link [15:48:07] we just had the app regression tested, and got a lot of feedback on "this image is low-res, cut off strangely" [15:48:21] * bgerstle is reminded of that "bad image" button thread he started.. [15:48:36] https://github.com/wikimedia/mediawiki-extensions-PageImages/blob/master/PageImages.body.php#L139 [15:49:09] * phuedx is reminded of all of the types of microcontribution we could've enabled [15:49:25] bgerstle: that function is the one that chooses the page image and sets the prop if it ain't there [15:50:44] bgerstle: https://github.com/wikimedia/mediawiki-extensions-PageImages/blob/master/PageImages.body.php#L303 [15:50:53] ^ that's the function that ultimately decides which image to choose [15:51:57] interesting [15:52:13] so actually it's not just the first image on the page, which i thought it was [15:52:15] there's nuance [15:57:58] but who scores them? [15:58:24] kaldari: legoktm btw, i'm noticing some discrepancies w/ the boolean fields [15:58:34] curl -s 'en.wikipedia.org/w/api.php?action=mobileview&prop=pageprops|editable&format=json&page=Main_Page&formatversion=2&onlyrequestedsections' [15:59:01] en.wikipedia.org/w/api.php?action=mobileview&prop=pageprops|editable&format=json&page=Main_Page&formatversion=2&onlyrequestedsections https://www.irccloud.com/pastebin/zdt8SAUt [15:59:16] note that editable is "false" while mainpage is an empty string [15:59:33] and on Barack_Obama, mainpage is absent (i.e. false) [16:01:41] and formatversion doesn't seem to do anything [16:01:51] phuedx: did you understand what i wrote here: https://gerrit.wikimedia.org/r/#/c/210649/5 i read it again and it sounds as i was a little bit confused by myself :D [16:03:36] ok, so it's replacing global state with a different type of global state that can be loaded from anywhere? [16:04:08] bgerstle: looking [16:04:20] legoktm: thanks [16:04:56] $resultObj->addValue( null, $moduleName, [16:04:56] array( 'mainpage' => '' ) [16:04:56] ); [16:04:57] sigh [16:05:03] teehee [16:05:21] legoktm: guess i have to wait for 1.26/27? [16:05:22] phuedx: in fact: yes :) [16:05:48] legoktm: want me to file a phab ticket w/ the URLs i was testing? [16:06:32] bgerstle: er, what do you mean wait? [16:06:40] https://gerrit.wikimedia.org/r/214636 is the patch [16:06:59] legoktm: until that's deployed, i mean [16:07:46] it should be like a week [16:07:53] depending on when it gets merged [16:08:45] legoktm: a week until i can count on it being on any wiki the app accesses? i.e. language wikis [16:09:00] it depends on when it gets merged [16:09:39] legoktm: i guess what i'm asking is: at what point would I rely on this field being a proper boolean in the app? [16:09:48] s/would/should/ [16:10:06] okay, for the third time. it depends on when the patch is merged. [16:10:11] legoktm: it should be true in formatversion 2, yes? [16:10:17] FlorianSW: yes [16:10:21] FlorianSW: we just found out it's not :-( [16:10:25] for mainpage, atl east [16:10:27] at least* [16:10:33] also, it seems to be true even if formatversion=2 is omitted [16:11:15] legoktm: if jenkins doesn't think to be bitchy, i'll merge it :) [16:11:19] legoktm: does your patch already fall back to the old behavior if formatversion=1 is specified? [16:11:25] bgerstle: shouldn't be [16:11:34] FlorianSW: see my example above [16:11:38] bgerstle: yes, did you read the commit message? [16:11:43] oh wait [16:12:27] legoktm: yes, but (and take this w/ a heaping of salt) i don't see where the check is being performed [16:12:39] but if you say it will, then that's ok [16:13:49] bgerstle: the ApiResult class in core automatically converts booleans into old-style empty strings with some fun magic, so developers can write code for formatversion=2 and in most cases formatversion=1 will be updated appropriately [16:13:55] FlorianSW legoktm: en.wikipedia.org/w/api.php?action=mobileview&prop=pageprops|editable&format=json&page=Main_Page&onlyrequestedsections https://www.irccloud.com/pastebin/DOu5sDRB [16:14:12] legoktm: i see, makes sense [16:14:33] legoktm: FlorianSW you can see that editable = false when formatversion param is omitted ^ [16:14:55] 'editable' => $editable, [16:14:55] ApiResult::META_BC_BOOLS => array( 'editable' ), [16:15:07] legoktm: also, if i specify formatverison=1 it's *still* false [16:15:27] bgerstle: that's because the API was emitting a raw boolean before the formatversion overhaul, but for back-compat it has to stay a boolean in formatversion=1 [16:15:48] so, formatversion only affect *specific* fields? [16:16:03] affects* [16:16:28] it affects all fields that don't have an exemption [16:16:38] so, only specific fields [16:16:46] i.e. not all fields [16:17:04] in this case 'editable' has META_BC_BOOLS because it was emitting a boolean beforehand and needed to continue emitting a boolean in formatversion=1 [16:17:36] FlorianSW: the test is flaky, it'll work a majority of the time, and it'll fail you if you're unlucky [16:18:38] legoktm: so client developers are expected to grep the code to double check that booleans are actually booleans and/or whether or not they'll respond to formatversion arguments? [16:19:21] legoktm: ok, i think we're unlucky :) (does it make sense to test it later?) [16:21:10] bgerstle: no, client developers should pick a formatversion and stick with it until they're ready to migrate to the next one, at which point they should check all API calls it makes to see what in the response has changed. Note that formatversion=2 is not considered stable due to issues like this one so you might want to wait a little while before adopting it. [16:22:56] legoktm: how do other people code around this? and how do they audit all their API calls? then, how do they even know when to push changes to their API calls (i.e. when they can be reasonably confident that the MW instances they're targeting will behave as they expect)? [16:23:55] are there any tasks/RFCs about a long-term solution to make this more reliable? [16:24:07] code around what? I'm not sure what the specific issue here is [16:24:36] legoktm: i have an object w/ a boolean field that I deserialize from an API response [16:24:56] for each boolean field, i need to manually check MW code to see what response I should expect [16:25:09] then, i need to check what version of MW will actually behave this way [16:25:21] then, I need to effectively write my own JSON parser to accommodate this unconventional behavior [16:26:20] my original question was: if/when this behavior stabilizes on standard JSON, it's unclear (to me at least) when I can "flip the switch" to request the new format. i'm guessing i would see when the patch is merged, and track it through the MW release process [16:26:29] lol, throwing in ridiculous hyperbole doesn't help [16:26:45] how is any of this ridiculous or hyperbolic? [16:26:56] " I need to effectively write my own JSON parser" [16:27:06] do you know any JSON parsers that read/write booleans this way? [16:27:12] and are configurable to support this? [16:27:15] JSON.stringify sure doesn't [16:27:34] I think you're overthinking this, but I'll ignore that for now. [16:27:52] someone needs to audit the mobileview module to make sure it is emitting booleans for all possible fields [16:27:58] if by "overthinking" you mean "remove code that shouldn't be necessary," than yes [16:28:07] and once they and you? are satisfied with the mobile, start using it. [16:28:39] the problem has been around for a long time that the mobileview module was inconsistent and formatversion is finally bringing it to light [16:28:58] like, wtf: array( 'viewable' => 'no' ) [16:29:16] legoktm: but formatversion is itself unreliable, requiring tedious cross-checking [16:29:34] no, you're confusing two different things [16:29:52] i'm focusing on one thing: reliable response schemas [16:29:57] formatversion is just a feature in core that does transformations on results. What's unreliable is the output from the mobileview response. [16:30:44] i thought the issue was more pervasive than just in mobileview [16:31:11] i.e. i figured this was something fundamental to JSON parsing in MW [16:31:19] "What's unreliable is the output from the mobileview response." | create_phab_task.sh [16:31:53] um, no [16:32:13] legoktm: so each module is left to do JSON parsing its own way? [16:32:29] most API modules followed the conventions of (originally) not using proper booleans, etc. but mobileview didn't so now the response is confusing [16:32:33] bgerstle: umm, no??? [16:32:40] API modules don't deal with JSON [16:32:56] how do they end up "not using proper booleans" then? [16:35:01] API modules used to add array( 'foobar' => '' ); aka not proper booleans, now they add array( 'foobar' => true ). The API formatversion=1 transformation code sees the raw boolean, and converts it into the empty string before sending to the client. This becomes confusing when the API module was previously emitting raw booleans. [16:36:10] ok, i see now [16:36:43] so it's simply a matter of going through and replacing the old convention w/ using actual booleans [16:36:59] and formatversion=1 should let clients get the old behavior if they want it [16:37:03] yep [16:38:01] legoktm: then would booleans being "true/false" despite formatverison=1 be a bug in formatversion? [16:38:12] * bgerstle e.g. en.wikipedia.org/w/api.php?action=mobileview&prop=pageprops|editable&format=json&page=Main_Page&onlyrequestedsections&formatversion=1 [16:38:16] no [16:38:26] https://www.irccloud.com/pastebin/gYbbZYI4 [16:38:39] i.e. "editable" should be omitted [16:38:45] if formatversion=1 is specified, right? [16:39:01] because that field was always a boolean before formatversion. And if we turned it into a not proper boolean, that would break clients, which IIRC it nearly did! [16:39:14] https://lists.wikimedia.org/pipermail/mobile-l/2015-April/009040.html [16:40:28] legoktm: you could let the "default" behavior be like this [16:40:53] but IMHO, if you specify formatversion=1, that's the client telling you "i want the 'false string for booleans' convention" [16:41:28] but, i don't really care about formatversion=1, so i'll let that be [16:42:44] so, back to mainpage... once your patch is merged and deployed, i can change our API calls to use formatversion=2 for true/false booleans [16:43:05] since, i guess you can't default to true/false booleans w/o breaking backwards compatibility [16:43:33] yes [16:43:35] also, where's the best place to document all of this? [16:44:00] i'm thinking the mobileview action [16:44:30] https://www.mediawiki.org/wiki/API:JSON_version_2 has a bunch of stuff [16:45:02] legoktm: sure, but since specific fields of specific responses behave certain ways, we probably need documentation closer to the actual API module [16:45:11] i.e. whoever "owns" the mainpage field [16:45:45] would say "type: Boolean — affected by [formatversion parameter](link/to/formatversion/docs)" [16:46:16] everything else that says "Boolean" should be assumed to have true/false, i guess [16:46:56] i'm only harping on this because i prefer things to be explicit over implicit [16:47:19] and want to avoid situations where API changes break things due to implicit client-server contracts [16:47:43] right. the API used to have something called getResultProperties which I guess the goal was to return a schema of response, but it was terribly implemented and didn't really work. There might be a WONTFIX bug about it somewhere [16:47:57] e.g. the stuff that gwicke is doing establishes a pretty clear (and potentially statically checkable) contract for response schemas *per API version* [16:48:07] sorry s/API/endpoint/ [16:48:24] sorry again s/gwice/services team(s)/ [16:49:35] I'd suggest first creating the response schema and then we can probably figure out how to get it into mobileview [16:50:04] legoktm: ok [16:50:15] thanks for shedding light on all of this [16:50:54] there are some plans for client-side devs to do more server-side work—and we've got a lot to learn. so i appreciate you being patient with me [16:51:08] anytime [16:51:09] (w/ consultation from experienced MW devs, of course) [16:52:54] ok, i'm going to create a phab task for this. looking at https://www.mediawiki.org/wiki/Extension:MobileFrontend#action.3Dmobileview [16:53:08] it's unclear if that's actually what needs to be documented [16:53:22] oh i see [16:53:30] i was looking at request params [16:53:38] where's the response docs (if there are any..) [16:54:10] you can see example responses, but there doesn't appear to be a response schema definition [16:54:27] which is what you were saying, legoktm [16:54:36] had to see it for myself :-P [16:54:53] legoktm: do you know of any other actions that have defined response schemas? [16:55:09] so we can follow any preexisting conventions [16:56:12] TemplateData has a schema, but I don't think that really counts, so no... [16:56:18] ok [16:56:24] * bgerstle writes phab tasks to document all response schemas [16:56:31] j/k we'll start w/ one and see how it goes :-P [16:57:00] bd808: have you been following this at all? [16:57:21] there's a lot of scrollback, so i can summarize if needed [16:57:26] tbh, most API modules are pretty simple so you usually don't need a formal schema to figure out what the response will be like (it would be a good idea anyways)...mobileview otoh is a behemoth. [16:57:30] bgerstle: nope. just saw the ping [16:57:58] e [16:58:03] ^ professional [16:58:22] * bd808 ducks back into -operations to talk about db errors [16:58:27] bd808: TL;DR; would be nice to have documented response schema(s) for mobileview [16:58:35] and perhaps other APIs [16:58:57] in a crazy world, we could use something like JSONSchema which allows for validation and code generation [16:59:25] http://json-schema.org/ [16:59:31] jsonschema doesn't work so well for xml ;) [16:59:46] remember that the api does many many things for many many people [16:59:50] "html": "string" # < done! [17:00:08] bd808: right, perhaps documenting its behavior might be insightful [17:00:14] s/might/would/ [17:00:26] provide some opportunities for refactoring, perhaps... [17:01:09] bd808: if anything, this would provide people using the API w/ a reference that tells them what they want to know, and establishes a contract that they can depend on [17:01:42] bd808: how do the devs even know what a response should look like given various inputs? [17:01:51] establishing a contract is tricky [17:01:58] api modules are not versioned [17:01:59] but well worth it, IMHO [17:02:21] changes are generally additiive [17:02:28] "generally" [17:02:33] yeah [17:02:47] but, breaking backwards compatibility is not uncommon [17:02:54] remember that this stuff goes back to 2005 or so [17:02:58] right [17:03:05] even more reason to plan for change [17:03:15] this is not a world the Roy Fielding imagined [17:03:46] the action api is optimized for large batch curation and editing operations by bots [17:04:03] which is good because without them enwiki would be a giant viagra ad [17:04:10] ok, but are you saying that to suggest that non-bot clients should use a different API? [17:04:34] bd808: also, those bots clients are just as vulnerable to breaking as others [17:04:44] i'm not even talking about the API *design* [17:04:57] I guess I'm saying that long-lived static contracts have never been a priority and versioning has been actively avoided [17:05:51] bd808: contracts don't need to be long-lived. you could (and should, IMO) deprecate and obsolete certain APIs as things change. [17:06:53] it sounds to me like we're saying: "stuff changes to often and is too complex to document and guarantee. read the source" [17:06:58] too often* [17:07:44] I think we can do better [17:07:49] but change will come slow [17:07:49] so do i :-) [17:08:15] Brad has been working hard to clean things up and make docs better [17:08:21] also, versioning seems to already be upon us (in a way I wouldn't have expected): https://www.mediawiki.org/wiki/API:JSON_version_2 [17:08:35] but I don't know if output schemas have been high on the list of shit to fix [17:08:55] i understand that documentation & schemas don't have the same curb appeal as a bug fix or a feature [17:09:04] but i still think they're important [17:09:06] json2 is a transitional thing [17:09:27] to avoid breaking everything that used the not-quite-json all at once [17:09:46] IOW, it's a (temporary) API versioning mechanism [17:09:53] and we are working on killing many of the output formats [17:09:59] which are crufty and gross [17:10:04] all for that [17:10:16] eg phpfm wddx yaml ... [17:10:36] why YAML? that's phuedx's favorite [17:10:47] anyway [17:10:53] it's useless for an api response [17:10:59] (sorry i was kidding) [17:11:01] josn is a proper subset of yaml [17:11:07] yes, yes, please kill yaml [17:11:19] * bd808 maintains the PECL YAML module ;) [17:11:38] bd808: so, let me put it this way: as a developer, how am I supposed to keep track of what my action does? [17:11:47] there has to be a spec *somewhere* [17:11:51] even if it's in the tests [17:11:55] the code [17:12:15] the code is an implementation detail and not user-friendly [17:12:35] the code is truth but yes not user friendly [17:12:58] that depends on your perspective [17:13:04] but i don't really want to get that philosophical [17:13:52] i guess what i'm saying, practically, concretely, is: i use mobileview. i want to write a client for mobileview. how do i write this client in a way that responds properly to all of its behaviors? [17:14:10] doesn't even need to be for mobileview in its entirety [17:14:22] I just want to query it a specific way that I know will work [17:14:26] and not change under my feet [17:15:01] IME, writing clients for MW is a trial & error process of sending example queries and inferring the schema [17:15:15] which leads to unexpected ambiguities like we're seeing today [17:16:59] i'd be curious to get their feedback, but I'd guess that people writing clients for their bot would also find these kinds of documents/contracts appealing [17:17:50] agreed. I'm not arguing that they can't/shouldn't be created. I think the problem may be more complex than it seems on the surface however [17:18:05] "just document things" sounds easy to many [17:18:42] bd808: i'm not trying to presume that it's simple or easy. [17:18:45] so yes, please start on something and see if you can make docs that feel useful [17:18:52] ok [17:19:05] and if you can then we can try to figure out how to get help making more of them [17:19:07] right, just want to see if there's traction for this sort of thing if we can prove that it's worthwhile [17:19:55] if the docs aren't somehow generated from the source though I fear that it will be futile [17:20:00] bd808: i said this earlier to legoktm, but if front-end devs are going to start working on services, then we need to make sure we're on the same page [17:20:08] bd808: right, definitely not what i had in mind [17:20:51] bd808: just to be clear: my goal is to have specs/docs that are as close to the source as possible [17:21:06] not just for api.php, but iOS too [17:21:54] so, now that we've come to this point, back to my original question. [17:21:59] now that we're all one happy reading team [17:22:02] how do we track this work? [17:22:42] is this something that should go on "your" backlog? is this something i'll have to do as a hack project? [17:23:32] you could make an epic in https://phabricator.wikimedia.org/tag/mediawiki-api/ to track the idea [17:23:44] ok [17:23:52] * bgerstle files a task to learn PHP [17:23:57] and then a spike task for one module [17:24:03] that's what i was thinking [17:24:29] sounds like a plan then :) [17:24:31] you know what they say "so goes mobileview..." [17:24:42] or something like that [17:24:52] mobileview is probably the most complex module that exists [17:25:09] it's a grab bag of "we need this now" as far as I know [17:25:17] off the top of your head, is anyone besides MFE & apps using it? [17:25:55] (it = mobileview) [17:25:58] bgerstle: bd808: ping S Page on the phab task, maybe he has ideas about how to do the documentation or wants to help [17:26:05] ok [17:26:07] thanks joakino [17:27:00] bd808: even if apps & web (i.e. mobile+desktop web) start using our own services, we'll need to talk to MW API modules at some point [17:27:21] i'll need to think about documenting mobileview versus something else that we'll definitely use going forward [17:29:40] ok, i think that's enough future-planning for today.. time to actually get something done [17:30:00] bd808: want me to CC you on any tasks I end up creating for this? [17:30:16] bgerstle: so the patch should be deployed to Wikipedias on June 3rd [17:30:26] bgerstle: sure [17:30:30] legoktm: w00t phab ticket? [17:30:41] I never filed any tickets [17:30:57] legoktm: ok, would be nice to know the MW version or something so i can track this [17:31:15] 1.26wmf8 [17:31:16] legoktm: would you mind filing a ticket for it so it can be tied to a MW release (not sure how this normally works)? [17:31:24] bd808: that's a perfect description of mobileview [17:31:38] i'd like to create a corresponding ticket on the iOS proj which is blocked by the MW change [17:32:16] bgerstle: you don't need to learn php per se, just to pair with some folk who are a little more comfortable with it [17:32:23] you drive, the other person codes and feeds back [17:32:25] might be fun [17:32:40] ^ not directly related to the discussion [17:32:45] i'll shut up now [17:32:57] bgerstle: I could create the task I guess, but it would be closed since it's fixed in master, so it wouldn't be super useful? [17:33:07] phuedx: http://weknowmemes.com/wp-content/uploads/2012/11/but-ask-but-yes-i-could-use-some-help.jpg [17:33:40] legoktm: ok, what about a task for deploying 1.26.wmf8? [17:33:57] (i thought tasks were closed when the corresponding release was closed) [17:34:06] or wait, that was a hackathon project [17:34:11] nvm [17:35:44] greg-g: is there a phab ticket for releasing 1.26.wmf8? [17:35:49] can't find it via search [17:42:50] for releasing? no, but there is https://phabricator.wikimedia.org/tag/wmf-deploy-2015-05-27_%281.26wmf8%29/ [17:43:01] the conjugated verb confused me :) [17:44:51] that project ^ is just a way to show things fixed/rolling out with that new branch [17:44:56] not sure what you're asking for [17:48:20] greg-g: i think that's what i was asking for precisely :-) [17:48:37] greg-g: i'd like to have a task blocked by a MW release [17:48:49] since the task for the relevant fix is already resolved after being merged to master [17:49:42] bd808: sorry, you mentioned that "formatversion" is temporary. is there a task to deprecate/obsolete it? [17:50:16] i.e. if i flip all of the app's requests to use "formatversion=2" do I also have to remove that parameter when formatversion stops being supported? [18:04:56] gonna take a break [18:26:50] MaxSem: is adam in the office today? [18:27:21] nope, kaldari - neither are you? :P [18:27:37] MaxSem: Nope, feeling sick today, so just working from home [19:46:48] zomg: https://percy.io/ [19:53:37] phuedx: you should post it on the wikitech-l list :-} [19:53:52] phuedx: I think https://applitools.com is similar [19:54:35] hashar: bbc's wraith project does the same thing over time [19:54:42] but it destroys my machine when i run it :/ [19:54:58] (https://bbc-news.github.io/wraith/index.html) [19:57:50] time to set it up on our jenkins ? :-} [19:58:29] visual diff is a recurring requests from frontend devs and designer [20:01:13] hashar: i'd happily help out -- experiment with mobilefrontend :D [20:01:39] diff against beta cluster and the patch? [20:03:18] bgerstle: I'm reading the scrollback... Yes, it would be nice for API modules to be able to specify return format. [20:03:58] spagewmf: much agreed [20:04:56] spagewmf: i can't spare much time at the moment to work on it, but would be happy to have a brainstorming session with you if you think it's worth working on before I get around to it [20:05:40] bgerstle: Yes there's uncertainty in whether modules return '' or true for boolean, whether they return anything for false. apiformat=2 gives module writers an *opportunity* to clean this up, but we're still fixing, hence legoktm's patch. [20:05:58] right [20:06:16] bgerstle: sure, schedule a hangout with me and anomie. It would help to have a concrete-ish proposal for mobileview [20:06:38] spagewmf: yeah, maybe we can start w/ something smaller, though [20:07:01] or (and this is a crazy idea) factor out a subset of mobileview's functionality into something else that's easier to document/guarantee [20:07:12] purely blue-sky stuff, but something to think about [20:07:22] I mean https://en.wikipedia.org/wiki/Special:ApiHelp/mobileview (a redirect), how can it tell you that hasvariants is a boolean, and if it returns false or leaves it out [20:07:31] when false [20:07:38] also fine starting w/ something like TextExtracts or siteinfo (which I'm working with as we speak, actually) [20:07:53] bgerstle: pageimages or textextracts [20:08:05] phuedx: you can't tell me what to do! [20:08:20] of course i can [20:08:21] :-P [20:08:49] it's not that mobileview has a large surface area, it's that its overly complex [20:09:31] i.e. this field returns strings when you specify formatversion=1234, but returns an associative array of xpath queries when you send a request while jumping on one foot [20:09:38] that kind of complex? ^ [20:09:59] i like siteinfo as a starting point [20:10:06] seems like a pretty straightforward repsonse [20:10:09] response* [20:10:14] maybe pageimages too [20:10:15] number of moving parts [20:10:51] k [20:10:53]