Architecture meetings/RFC review 2014-03-26

21:00 UTC, March 26th, at.

Requests for Comment to review

 * 1) Allow styling in templates - Jon Robson
 * 2) Minifier - MaxSem

Meeting summary

 * LINK: : https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-26 (sumanah, 21:10:42)
 * Today we're covering 2 RfCs: Jon Robson's proposal regarding styling in templates, and MaxSem's minifier proposal (sumanah, 21:10:42)
 * Brion and Tim aren't here today so we're basically articulating & clarifying what needs doing/deciding. (sumanah, 21:11:01)
 * Styling in templates (sumanah, 21:11:10)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates (sumanah, 21:11:10)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Deprecating_inline_styles was an older RfC that Jon abandoned in favour of "Allow styling in templates" (sumanah, 21:11:10)
 * LINK: https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Allow_styling_in_templates We discussed this topic during the Architecture Summit in January (sumanah, 21:11:10)
 * the next steps from January said - Jon & friends would lock down some details, code up a prototype/working beta with some sample templates, and so on by about the end of March. (sumanah, 21:11:31)
 * Jon wants: "some agreement on the way forward and someone with time to write the code to get this kicked off :) i've been a bit swamped recently"  (sumanah, 21:12:00)
 * (we were supposed to talk about this in February https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27 but ran out of time in that meeting) (sumanah, 21:12:54)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces (marktraceur, 21:14:15)
 * Jon looked at supporting style tags rather than separate wiki pages for styles, per discussion at the summit, and it was nasty and required messing with the parser. https://gist.github.com/anonymous/9262427  (sumanah, 21:23:36)
 * discussion of having a separate Template:Foo.css page; see https://gerrit.wikimedia.org/r/68123 (sumanah, 21:23:36)
 * discussion of sanitizing/making secure CSS and content, and performance implications of having a separate CSS bundle (sumanah, 21:23:36)
 * IDEA: could we have ResourceLoader bundle it? (sumanah, 21:23:36)
 * HELP: Jon needs help writing the code to get this kicked off (sumanah, 21:30:20)
 *  However we do this, this would definitely need ops buy in of some sort (at least notifications) (sumanah, 21:33:01)


 * Minifier (sumanah, 21:37:58)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Minifier (sumanah, 21:37:58)
 * Max wants to move forward with this (sumanah, 21:37:58)
 * after gzipping, Max's proposal would provide a 10-20% saving in payload, which would be great; need to check on increase in system complexity, possible client-side performance impact (sumanah, 21:49:41)
 * ACTION: MaxSem to make a plan to evaluate impact thoroughly (sumanah, 21:50:12)
 * IDEA: Could this be done as a beta feature first to get some real data behind the improvements? we could use PerformanceTiming extension (sumanah, 21:52:39)
 * RfCs on Ops's radar:
 * https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_interfaces
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Simplify_thumbnail_cache (sumanah, 21:59:51)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/CentralNotice_Caching_Overhaul_-_Frontend_Proxy (sumanah, 21:59:54)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener (less urgent maybe) (sumanah, 21:59:59)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging (sumanah, 22:00:02)

Meeting ended at 22:04:30 UTC.

Action items

 * MaxSem to make a plan to evaluate impact thoroughly

Full log
21:10:35 #startmeeting RfC review (styling in templates & minifier) | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours 21:10:35  Meeting started Wed Mar 26 21:10:35 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:10:35  Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:10:35  The meeting name has been set to 'rfc_review__styling_in_templates___minifier____channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' 21:10:40 Wait. Slammin slalomin' salmons 21:10:42 #link: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-26 21:10:42 #info Today we're covering 2 RfCs: Jon Robson's proposal regarding styling in templates, and MaxSem's minifier proposal 21:10:44 * marktraceur is done 21:11:01 #info Brion and Tim aren't here today so we're basically articulating & clarifying what needs doing/deciding. 21:11:10 #topic Styling in templates 21:11:10 #link https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates 21:11:10 #link https://www.mediawiki.org/wiki/Requests_for_comment/Deprecating_inline_styles was an older RfC that Jon abandoned in favour of "Allow styling in templates" 21:11:10 #link https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Allow_styling_in_templates We discussed this topic during the Architecture Summit in January 21:11:31 #info the next steps from January said - Jon & friends would lock down some details, code up a prototype/working beta with some sample templates, and so on by about the end of March. 21:11:40 * Krinkle peeks 21:11:46 jdlrobson: do you have that to show? 21:12:00 #info Jon wants: "some agreement on the way forward and someone with time to write the code to get this kicked off :) i've been a bit swamped recently" 21:12:53 SO during the architect summit there was a strong desire for the support of style tags rather than separate wiki pages for styles 21:12:54 #info (we were supposed to talk about this in February https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27 but ran out of time in that meeting) 21:13:05 I attempted to go down that rabbit hole but this requires messing with the parser - https://gist.github.com/anonymous/9262427 21:13:09 It's nasty basically. 21:13:21 So I'd like to revisit the idea of having a separate page 21:13:32 e.g. Template:Foo.css rather than exploring tags 21:13:59 So does this intersect with the related-namespace RFC? 21:14:15 https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces 21:14:16 as this seems much more doable and will allow us to quickly get an idea if 1) editors would use them 2) If they promote code sharing 21:14:25 * jdlrobson looks 21:14:28  jdlrobson: if it is a separate file, would it have to be bundled/loaded separately? Or just bundled in as a TAG? 21:14:58  jdlrobson: is using a tag a hard requirement? couldn't we just use something that doesn't conflict with HTML tag names? 21:15:06 Not sure. I imagined it would be the Template namespace and work in a similar fashion to MediaWiki namespace 21:15:32 e.g. just the addition of .css on the same would turn it into a template stylesheet and it could be included in a similar fashion 21:16:00 jdlrobson: Yeah, but magically tying together things that have .css to things with the same name without .css seems broken 21:16:06 (see original proof of concept - https://gerrit.wikimedia.org/r/68123) 21:16:17 Or at least like an assumption we don't want to make 21:16:31 This would enforce any template ending with .css gets treated as a css file 21:17:05  if it is going to be loaded as a separate bundle of CSS, that'll also have performance implications. 21:17:37 MatmaRex: The style tag is not a hard requirement, but I'd rather use a style tag so that people familiar with HTML don't have to learn yet another bit of wikitext 21:17:42  jdlrobson: is the fact that the parser is all kinds of terrible the only reason tags inline are a problem? 21:18:14  jdlrobson: would the semantics be exactly the same? (genuine question, i don't know) 21:18:20 tags are really hard to make secure 21:18:20 YuviPanda: pretty much - I've been struggling to find time to work on this but if someone can find a nice elegant way of doing this they would win lots of brownie points (CR points ;-)) fo�rom me 21:19:15 csteipp: can you elaborate? Could we not use the same CSS sanitizer we have in ResourceLoader on the contents of a style tag? 21:19:24  yeah, what csteipp said. Scoped support doesn't really exist yet, I think :( 21:19:32 That css sanitizer doesn't sanitize selectors 21:19:39 or @ rules 21:20:08 Scoped CSS can be achieved via a shim 21:20:27 jdlrobson: Maybe-- I haven't looked at it. But in general, you need a fair amount of processing on those, and adding that into the parser would be ugly. 21:20:45 csteipp: yeh which is why i'd like to push us in the direction of a separate wiki page.. :) 21:21:16 jdlrobson: I totally agree! I was commenting on Yuvi's inlining comment :) 21:21:30 jdlrobson: What was the issue with using a parser tag? There would be some amount of parser magic involved, but doesn't seem that impossible (I say that without trying) 21:21:32 This didn't get much support during the architect summit 21:21:54  jdlrobson: if you have a separate page, would that get loaded as a separate HTTP request? 21:21:55 There is perhaps non-technical reasons why we might want a separate page though 21:22:28  or would all the template CSS be loaded as a single HTTP request? 21:22:51 * bawolff assumes we would want to RL it (?) 21:22:57  YuviPanda: i haven't tried either, but i think we could have RL magically bundle it 21:23:11  MatmaRex: right, but then you will still have to scope it 21:23:21  as in, it should Just Work 21:23:36 #info Jon looked at supporting style tags rather than separate wiki pages for styles, per discussion at the summit, and it was nasty and required messing with the parser. https://gist.github.com/anonymous/9262427 21:23:36 #info discussion of having a separate Template:Foo.css page; see https://gerrit.wikimedia.org/r/68123 21:23:36 #info discussion of sanitizing/making secure CSS and content, and performance implications of having a separate CSS bundle 21:23:36 #idea could we have ResourceLoader bundle it? 21:23:36 bawolff: trying to remember it's been a while since i coded that 21:23:38 So if we had it on a separate page, is the plan to have something like CSS:Page_Name_Here 21:23:46 * sumanah tries to summarize for the notes 21:23:47  YuviPanda: hmm, i think jdlrobson just wanted to wrap the user-provided styles in some LESS? 21:23:50 bawolff: actually we probably wouldn't RL it 21:23:57 <YuviPanda> MatmaRex: ah, hmm. 21:24:10 <YuviPanda> MatmaRex: hmm, right. that makes sense. Just prefix all selectors. 21:24:11 or is the plan CSS:Any_identifier_here, and then include it with 21:24:14 or something else 21:24:14 <MatmaRex> as in, #whatever { <all CSS goes here> } 21:24:27 jdlrobson: Why not? 21:24:39 <YuviPanda> MatmaRex: right. as long as we can test it and make sure they can't break out of it that sounds sane enough. 21:24:56 bawolff: TrevorParscal had some great reasons I'm trying to dig that out 21:25:02 or hoping TrevorParscal can chip in 21:25:30 It was to do with caching but I can't remember off the top of my head :-( - as i said i've been swamped 21:26:04 I thought the whole point of RL was to make caching of CSS not suck :) 21:26:05 So, Jon wants someone to help write the prototype. Any volunteers? 21:26:34 there's a VisualEditor quarterly review right now so Roan/Trevor aren't super available to chat, but maybe we could talk onlist - I think I saw Krinkle peek in earlier 21:26:38 bawolff: i remember.. 21:26:50 so say a page includes Template A.... 21:27:42 and Template A includes a stylesheet B. If B gets edited, the page now has the markup of Template A but the new styles of Template B - as RL gets round caching. 21:28:04 If you do it as inline style tags then the page still runs with the old style tags 21:28:36 Oh right, RL caching is faster then page caching 21:29:33 Most of the time, the time difference wouldn't be that significant (I think, might be wrong) 21:30:20 #help Jon needs help writing the code to get this kicked off 21:30:25 <MatmaRex> bawolff: well, this caused us to break things a few times in reviewed code 21:30:39 * MatmaRex broke it once before i learned how this stuff works 21:30:55 MatmaRex: Yes, but when changing in code review, it doesn't purge the pages that use it, unlike when a user edits 21:31:01 <MatmaRex> total havoc, let me tell you. i bet it'd be worse when completely no one would know what is going on, instead of almost no one 21:31:15 <MatmaRex> purging can take days, too 21:31:29 I think it would be safer and quicker as a first step to have a separate page for CSS 21:31:29 jdlrobson: would you like to mark any particular agreements with #agreed (e.g. the selector stuff) and then we will move on to Max's proposal and then probably break early and continue discussing onlist/onwiki? unless you want to discuss this more right now 21:31:43 yeah, that's unfortunate :(, sometimes its fast... 21:31:43 If we can demonstrate the success of that, I'm confident we can find the time to invest in style tags 21:32:08 <MatmaRex> we'd have to somehow additionally version the CSS within RL or something, and that smells nasty 21:32:23 <YuviPanda> However we do this, this would definitely need ops buy in of some sort (at least notifications) 21:33:01 #info <YuviPanda> However we do this, this would definitely need ops buy in of some sort (at least notifications) 21:33:16 <TimStarling> sorry I'm late 21:33:28 #chair TimStarling sumanah 21:33:28 <wm-labs-meetbot> Current chairs: TimStarling sumanah 21:33:31 sumanah: this is fine. I could just do with the help making this happen. I think everyone is bought into the idea just not the how. 21:34:16 jdlrobson: I think it would be an interesting thing to poke at ( for experiment purposes if nothing else), but I'll probably not get around to actually helping :s 21:34:20 bharris: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140326.txt in case you want the log 21:34:39 bawolff: that would be appreciated 21:34:55 * bawolff notes I can't garuntee anything 21:35:43 TimStarling: would you prefer to catch up on the discussion so far, or just continue the styling/templates discussion onlist/onwiki and instead move on right now to MaxSem's minifier proposal? 21:36:08 <TimStarling> were there any questions for me specifically? 21:36:47 <TimStarling> if not then we can move along to the next one 21:37:22 I think Jon needs a hand in coding the prototype before he'll have a question for you, so I think we can move along for now 21:37:58 #topic Minifier 21:37:58 #link https://www.mediawiki.org/wiki/Requests_for_comment/Minifier 21:37:58 #info Max wants to move forward with this 21:39:08 <MaxSem> First of all, does anyone have fundamental objections against this? 21:39:18 <TimStarling> it's nice to se that there will finally be a way to disable minification 21:39:41 <TimStarling> you know how long I argued for that in the RL design discussions 21:40:12 <TimStarling> assuming Krinkle's comment is correct, that is 21:41:22 MaxSem: I think that Trevor/Roan/Jon and other frontendy people might have opinions about this, yes? 21:42:42 <MaxSem> Roan is favorable, haven't seen a detailed analysis of the implementation yet 21:42:54 <MaxSem> jdlrobson, what's your opinion? 21:43:07 <TimStarling> so we are talking about a 10-20% saving? 21:43:25 <MaxSem> yes 21:43:30 <MaxSem> after gzipping 21:44:56 <TimStarling> I suppose that is not to be sniffed at 21:45:47 from #mediawiki: " sumanah: I've chatted with MaxSem about it; I guess I should reply on-wiki. I basically just want a plan for how we're going to evaluate the impact of this change" 21:46:32 it shrinks the payload. I'm not sure why this would be a bad thing. We should definitely check if there is any client side performance impact though. 21:46:50 <TimStarling> well, shrinking the payload is not a bad thing 21:47:15 Could this be done as a beta feature first to get some real data behind the improvements? 21:47:16 <TimStarling> increasing the complexity of the system is a bad thing 21:47:39 <TimStarling> you know that ops have almost no time to spend on anything 21:47:39 we could use PerformanceTiming extension 21:48:17 <TimStarling> the cost in system complexity has to be weighed against the improvements in user experience 21:48:43 TimStarling: agreed, so as ori states we should be sure that we measure this well and show that the gain is worth the pain 21:49:41 #info after gzipping, Max's proposal would provide a 10-20% saving in payload, which would be great; need to check on increase in system complexity, possible client-side performance impact 21:50:12 #action MaxSem to make a plan to evaluate impact thoroughly 21:50:23 maybe I shouldn't have said "great" - ah well. "good" 21:50:37 <TimStarling> we really should include ops in the SOA discussion generally 21:50:57 <MaxSem> The problem with measuring vs. complexity that in order to test it realistically we would need to implement most of it, including taking precious ops time:) 21:51:01 absolutely TimStarling - Faidon I suppose? 21:51:24 * sumanah knows Bergsma has his hands full 21:51:25 <TimStarling> mark 21:51:46 <TimStarling> he probably does, but he is probably interested in whether his hands are going to be fuller in future 21:52:02 <TimStarling> and he has been interested in this sort of thing in the past 21:52:03 Tim, please go ahead and invite him - I think it'd mean more coming from you than from me :) 21:52:11 :) 21:52:17 oh hi Mark 21:52:39 #idea Could this be done as a beta feature first to get some real data behind the improvements? we could use PerformanceTiming extension 21:52:41 yes, it's true, I have my hands really full, but I'd like to participate for RFCs/topics that are really relevant to me 21:52:53 SOA among them 21:53:14 mark: https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_interfaces would be one for you to check out, then 21:53:17 <TimStarling> what do you think of SOA generally? do you think it is doable? 21:53:41 i'm really not an expert on mediawiki internals of course, but yes, I believe it should be doable 21:53:46 <TimStarling> I mostly worry about increasing the number of ganglia clusters, monitoring capacity headroom, etc. 21:54:07 <TimStarling> I mean, the ganglia interface is kind of strained at the moment 21:54:21 yes but monitoring needs improvements anyway 21:54:30 <TimStarling> there would be more load balancers, so more paging checks in nagios 21:54:49 and having separate services more restricted to certain tasks with a good API and possibly SLAs will actually help monitoring 21:55:00 i'd gladly have that sort of problem tim ;) 21:55:04 <TimStarling> I mean icinga (please don't sue me) 21:55:25 right now it's all funnel into "the app servers" and god knows what happens there, from our perspective ;) 21:55:35 <TimStarling> ok 21:56:13 <TimStarling> what do you think about splitting up the gmetad server 21:56:33 <MaxSem> mark, any thoughts about minification _service_?:) 21:56:34 <TimStarling> then you get an extra hierarchy level in the UI 21:56:48 yeah that's something we can look at 21:56:56 there are even proposals to replace ganglia entirely, and a lot more 21:57:02 <TimStarling> you remember, that's what I did when I set it up in the first place 21:57:03 i don't think that will happen 21:57:05 i like ganglia 21:57:16 <TimStarling> the lack of multicast routing wasn't actually the reason for splitting gmetad 21:57:17 it's good to keep around nomatter what else we put up 21:58:06 <TimStarling> anyway, MaxSem wants to know what you think about minification 21:59:27 btw, https://www.mediawiki.org/wiki/Requests_for_comment/Scoped_language_converter next week's RfC chat - cscott will be asking for things I presume :-) 21:59:51 and mark I'd say there are 4 more RfCs it might be good for you to say something about, in addition to SOA stuff: 21:59:51 https://www.mediawiki.org/wiki/Requests_for_comment/Simplify_thumbnail_cache 21:59:54 https://www.mediawiki.org/wiki/Requests_for_comment/CentralNotice_Caching_Overhaul_-_Frontend_Proxy 21:59:59 https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener (less urgent maybe) 22:00:02 https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging 22:00:19 <TimStarling> mark: you did ask for it 22:00:35 <TimStarling> ;) 22:00:50 TimStarling: :) feel free to add to or subtract from that list, as your eye is more discerning 22:03:59 <TimStarling> I guess that is everything then? 22:04:04 * sumanah waits for mark to speak about MaxSem's stuff, or to endmeeting 22:04:27 I say we end 22:04:30 #endmeeting