Jump to content

Architecture meetings/RFC review 2014-03-26

From mediawiki.org

21:00 UTC, March 26th, at #wikimedia-office connect.

Requests for Comment to review

[edit]
  1. Allow styling in templates - Jon Robson
  2. Minifier - MaxSem

Summary and logs

[edit]

Meeting summary

[edit]


Meeting ended at 22:04:30 UTC.


Action items

[edit]
  • MaxSem to make a plan to evaluate impact thoroughly


Full log

[edit]
Meeting 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
Retrieved from "https://www.mediawiki.org/w/index.php?title=Architecture_meetings/RFC_review_2014-03-26&oldid=941525"