Architecture meetings/RFC review 2014-03-26
21:00 UTC, March 26th, at #wikimedia-office connect.
Requests for Comment to review
edit- Allow styling in templates - Jon Robson
- Minifier - MaxSem
Summary and logs
editMeeting summary
edit- 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 <style> 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)
- <YuviPanda> 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: <jdlrobson> Could this be done as a beta feature first to get some real data behind the improvements? <jdlrobson> 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
edit- MaxSem to make a plan to evaluate impact thoroughly
Full log
editMeeting logs |
---|
21:10:35 <sumanah> #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 <wm-labs-meetbot> 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 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:10:35 <wm-labs-meetbot> 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 <marktraceur> Wait. Slammin slalomin' salmons 21:10:42 <sumanah> #link: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-26 21:10:42 <sumanah> #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 <sumanah> #info Brion and Tim aren't here today so we're basically articulating & clarifying what needs doing/deciding. 21:11:10 <sumanah> #topic Styling in templates 21:11:10 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates 21:11:10 <sumanah> #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 <sumanah> #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 <sumanah> #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 <sumanah> jdlrobson: do you have that to show? 21:12:00 <sumanah> #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 <jdlrobson> 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 <sumanah> #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 <jdlrobson> I attempted to go down that rabbit hole but this requires messing with the parser - https://gist.github.com/anonymous/9262427 21:13:09 <jdlrobson> It's nasty basically. 21:13:21 <jdlrobson> So I'd like to revisit the idea of having a separate page 21:13:32 <jdlrobson> e.g. Template:Foo.css rather than exploring <style> tags 21:13:59 <marktraceur> So does this intersect with the related-namespace RFC? 21:14:15 <marktraceur> https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces 21:14:16 <jdlrobson> 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 <YuviPanda> jdlrobson: if it is a separate file, would it have to be bundled/loaded separately? Or just bundled in as a <style> TAG? 21:14:58 <MatmaRex> jdlrobson: is using a <style/> tag a hard requirement? couldn't we just use something that doesn't conflict with HTML tag names? 21:15:06 <jdlrobson> Not sure. I imagined it would be the Template namespace and work in a similar fashion to MediaWiki namespace 21:15:32 <jdlrobson> 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 <marktraceur> jdlrobson: Yeah, but magically tying together things that have .css to things with the same name without .css seems broken 21:16:06 <jdlrobson> (see original proof of concept - https://gerrit.wikimedia.org/r/68123) 21:16:17 <marktraceur> Or at least like an assumption we don't want to make 21:16:31 <jdlrobson> This would enforce any template ending with .css gets treated as a css file 21:17:05 <YuviPanda> if it is going to be loaded as a separate bundle of CSS, that'll also have performance implications. 21:17:37 <jdlrobson> 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 <YuviPanda> jdlrobson: is the fact that the parser is all kinds of terrible the only reason <style> tags inline are a problem? 21:18:14 <MatmaRex> jdlrobson: would the semantics be exactly the same? (genuine question, i don't know) 21:18:20 <csteipp> <style> tags are really hard to make secure 21:18:20 <jdlrobson> 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 <jdlrobson> 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 <YuviPanda> yeah, what csteipp said. Scoped <style> support doesn't really exist yet, I think :( 21:19:32 <bawolff> That css sanitizer doesn't sanitize selectors 21:19:39 <bawolff> or @ rules 21:20:08 <jdlrobson> Scoped CSS can be achieved via a shim 21:20:27 <csteipp> 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 <jdlrobson> csteipp: yeh which is why i'd like to push us in the direction of a separate wiki page.. :) 21:21:16 <csteipp> jdlrobson: I totally agree! I was commenting on Yuvi's inlining comment :) 21:21:30 <bawolff> jdlrobson: What was the issue with using a <style> 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 <jdlrobson> This didn't get much support during the architect summit 21:21:54 <YuviPanda> jdlrobson: if you have a separate page, would that get loaded as a separate HTTP request? 21:21:55 <bawolff> There is perhaps non-technical reasons why we might want a separate page though 21:22:28 <YuviPanda> 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 <MatmaRex> YuviPanda: i haven't tried either, but i think we could have RL magically bundle it 21:23:11 <YuviPanda> MatmaRex: right, but then you will still have to scope it 21:23:21 <MatmaRex> as in, it should Just Work 21:23:36 <sumanah> #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 <sumanah> #info discussion of having a separate Template:Foo.css page; see https://gerrit.wikimedia.org/r/68123 21:23:36 <sumanah> #info discussion of sanitizing/making secure CSS and <style> content, and performance implications of having a separate CSS bundle 21:23:36 <sumanah> #idea could we have ResourceLoader bundle it? 21:23:36 <jdlrobson> bawolff: trying to remember it's been a while since i coded that 21:23:38 <bawolff> 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 <MatmaRex> YuviPanda: hmm, i think jdlrobson just wanted to wrap the user-provided styles in some LESS? 21:23:50 <jdlrobson> 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 <bawolff> or is the plan CSS:Any_identifier_here, and then include it with {{#magicIncludeCss:Any_identifier_here}} 21:24:14 <bawolff> or something else 21:24:14 <MatmaRex> as in, #whatever { <all CSS goes here> } 21:24:27 <bawolff> 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 <jdlrobson> bawolff: TrevorParscal had some great reasons I'm trying to dig that out 21:25:02 <jdlrobson> or hoping TrevorParscal can chip in 21:25:30 <jdlrobson> 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 <bawolff> I thought the whole point of RL was to make caching of CSS not suck :) 21:26:05 <sumanah> So, Jon wants someone to help write the prototype. Any volunteers? 21:26:34 <sumanah> 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 <jdlrobson> bawolff: i remember.. 21:26:50 <jdlrobson> so say a page includes Template A.... 21:27:42 <jdlrobson> 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 <jdlrobson> If you do it as inline style tags then the page still runs with the old style tags 21:28:36 <bawolff> Oh right, RL caching is faster then page caching 21:29:33 <bawolff> Most of the time, the time difference wouldn't be that significant (I think, might be wrong) 21:30:20 <sumanah> #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 <bawolff> 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 <jdlrobson> I think it would be safer and quicker as a first step to have a separate page for CSS 21:31:29 <sumanah> 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 <bawolff> yeah, that's unfortunate :(, sometimes its fast... 21:31:43 <jdlrobson> 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 <sumanah> #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 <sumanah> #chair TimStarling sumanah 21:33:28 <wm-labs-meetbot> Current chairs: TimStarling sumanah 21:33:31 <jdlrobson> 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 <bawolff> 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 <sumanah> bharris: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140326.txt in case you want the log 21:34:39 <jdlrobson> bawolff: that would be appreciated 21:34:55 * bawolff notes I can't garuntee anything 21:35:43 <sumanah> 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 <sumanah> 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 <sumanah> #topic Minifier 21:37:58 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Minifier 21:37:58 <sumanah> #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 <sumanah> 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 <sumanah> from #mediawiki: "<ori> 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 <jdlrobson> 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 <jdlrobson> 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 <jdlrobson> 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 <jdlrobson> 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 <sumanah> #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 <sumanah> #action MaxSem to make a plan to evaluate impact thoroughly 21:50:23 <sumanah> 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 <sumanah> 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 <sumanah> Tim, please go ahead and invite him - I think it'd mean more coming from you than from me :) 21:52:11 <mark> :) 21:52:17 <sumanah> oh hi Mark 21:52:39 <sumanah> #idea <jdlrobson> Could this be done as a beta feature first to get some real data behind the improvements? <jdlrobson> we could use PerformanceTiming extension 21:52:41 <mark> 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 <mark> SOA among them 21:53:14 <sumanah> 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 <mark> 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 <mark> 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 <mark> and having separate services more restricted to certain tasks with a good API and possibly SLAs will actually help monitoring 21:55:00 <mark> i'd gladly have that sort of problem tim ;) 21:55:04 <TimStarling> I mean icinga (please don't sue me) 21:55:25 <mark> 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 <mark> yeah that's something we can look at 21:56:56 <mark> 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 <mark> i don't think that will happen 21:57:05 <mark> i like ganglia 21:57:16 <TimStarling> the lack of multicast routing wasn't actually the reason for splitting gmetad 21:57:17 <mark> 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 <sumanah> 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 <sumanah> 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 <sumanah> https://www.mediawiki.org/wiki/Requests_for_comment/Simplify_thumbnail_cache 21:59:54 <sumanah> https://www.mediawiki.org/wiki/Requests_for_comment/CentralNotice_Caching_Overhaul_-_Frontend_Proxy 21:59:59 <sumanah> https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener (less urgent maybe) 22:00:02 <sumanah> 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 <sumanah> 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 <sumanah> I say we end 22:04:30 <sumanah> #endmeeting |