[16:50:22] reminder: RFC review meeting in 10 min here [16:50:51] https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21 [16:54:47] So the rfc meeting is at 17:00 utc, and then there is a multimedia team office hours at 18:00. Isn't that cutting things a bit close together? [16:55:00] the rfc meeting is an hour [16:56:00] #startmeeting [16:56:00] sumanah: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' [16:56:06] AHA it's here already [16:56:08] never mind [16:58:01] HTML templating summary is at https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal [16:58:30] #startmeeting RFC review feb 21 on HTML templating and Services & narrow interfaces [16:58:30] Meeting started Fri Feb 21 16:58:30 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. [16:58:30] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [16:58:31] The meeting name has been set to 'rfc_review_feb_21_on_html_templating_and_services___narrow_interfaces' [16:58:36] #info HTML templating summary is at https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal [16:59:31] (waiting 30 seconds for more people to show) [16:59:41] * aude waves [17:00:34] hi there! [17:00:37] ok let's start [17:00:42] hi Sumana! [17:00:44] #info https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21 [17:01:19] * sumanah invites Brion into the room [17:01:20] I poked Brion [17:01:24] :) [17:01:34] rfc time? yeahhhhh [17:01:36] Hi brion! [17:01:45] so today we have https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21 [17:01:47] I'm fly-on-the-walling this one [17:01:51] HTML templating and Services & narrow interfaces [17:02:13] #info also today we'll have very quick checkins on performance guidelines and architecture guidelines [17:02:27] evening [17:02:35] gwicke: which do you want to start with? HTML templating or interfaces/services? [17:02:39] welcome all [17:02:45] HTML templating [17:02:49] #topic HTML templating [17:03:07] clarification re SOA: this is really about packaging as mentioned in the SOA RFC [17:03:29] so repository setup, upload procedures, use of debs for service deployments [17:03:33] excellent [17:03:43] I have asked Faidon to attend if possible, hope he pops in later [17:04:02] so lets start with HTML templating [17:04:02] hi paravoid! [17:04:05] hello! [17:04:20] paravoid: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140221.txt for logs till now :) [17:04:30] thank you sumanah [17:04:39] the basics are discussed in https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal [17:05:08] after the architecture summit the question was whether we can have a secure yet performant solution [17:05:30] we prototyped things and can now answer that question with 'yes' [17:05:33] I can read Twig/Mustache/similar without knowing the language, but not this proposal's markup [17:05:54] I've left my thoughts on the talk page of the new proposal [17:06:20] so, syntax; we looked at several DOM-based syntaxes out there [17:06:59] most are attribute-based, as that makes sense if your scopes match the DOM structure [17:07:36] the knockout syntax is fairly simple (JS object notation in a single data-bind attribute) [17:07:40] * brion is skimming [17:07:54] is data-bind content syntax plain json or kinda a domain-specific language? [17:08:09] It looks a lot like YADSL to me [17:08:22] it is slightly extended from json, but can be parsed in less than 100 lines [17:08:34] a shallow parse at least [17:08:36] *nod* [17:08:38] I think the syntax is a concern-- probably one we can live with, but my agenda for getting something standardized is that people use it.. so if the syntax is intimidating, then I'm definitely concerned. [17:08:42] good morning! catching up from the logs. [17:08:42] https://github.com/gwicke/TemplatePerf/blob/master/QuickTemplate/KnockoutExpression.js [17:08:48] Which in my opinion is pretty annoying and a bad decision on the framework authors' part [17:08:55] RoanKattouw, yadsl = yet another dsl? [17:09:14] But I also think that the library as a whole might be the least bad option [17:09:15] subbu: I think RoanKattouw means the tertiary meaning, Yet Another Domain Specific Language. [17:09:19] subbu: Yeah [17:09:31] in quicktemplate we restrict things to basically dot notation [17:10:07] *quicktemplate being the current working name for the intermediate language processor [17:10:14] the main reasoning is that we want to keep things simple for now, and want to encourage portability and clear model / template separation [17:10:49] i like the separation of data model and template; not totally against a slight domain-specific language for the data bindings, but yeah readability and maintainability are important [17:10:50] gwicke: you mention you benchmarked the solutions. could you publish your numbers? [17:10:52] we basically implement a simple subset of knockoutjs expressions [17:11:06] robla, you can pull the repo & run them yourself [17:11:06] (btw bebirchall how much is this topic related to https://www.mediawiki.org/wiki/User:5xbe/Proposal ?) [17:11:11] I assume QT in the examples refers to quicktemplate and not the QT C++ framework… [17:11:15] So, from my perspective, the reason we built out template system was to allow us to build more complicated special pages and other "application" elements. [17:11:18] marcoil, correct [17:11:19] gwicke: or...you could do it :-) [17:11:33] the numbers are better than compiled handlebars templates [17:11:35] so it's a lot like quick templates, with some slightly different design decisions because we had the freedom to do that [17:12:04] which are the fastest other library in the test so far [17:12:59] it sounds like there's an additional desire for you guys to have a templating system that also works for user content / wikitext. [17:13:04] gwicke, how much weight does it add to the page load? [17:13:25] 16k + a bit as Nikerabbit mentioned in the comments [17:13:28] one question to address would be how much peak performance weighs into decision of a templating system vs. syntax and other desirables [17:13:34] the syntax is fairly flexible; we picked knockoutjs as a starting point as there is a good implementation & it is close to what we want [17:13:34] gwicke: Preliminary numbers would be nice for everyone to see. Also, the code I looked at had a lot of "TODO: sanitize the attributes"... do we have a prototype that does sanitization that you've benchmarked? [17:13:36] #info Roan's concerned with the Knockout syntax being intimidating to people [17:13:51] #info brion likes separating the template from the data model [17:13:55] sumanah: I did not say that [17:13:59] we also have a second compiler from spacebars syntax to JSON IR [17:13:59] generally i wouldn't be concerned about speed unless it's amazingly slow. [17:14:18] I agree with brion [17:14:24] #info CSteipp is concerned about the syntax being intimidating, not Road :) [17:14:31] road? [17:14:32] csteipp, I was shooting for an apples-to-apples comparison for now [17:14:37] RoanKattouw: ok, sorry for missynthesizing there - trying to #info some stuff to get it into the simplified meeting summary [17:14:39] csteipp has a cold :-) [17:14:44] :) [17:14:45] in my opinion, all html templating library syntax is going to be "uglier" than plain string templating. so, i think some of that is unavoidable. [17:14:48] jgonera, something to note is that although we're using ko syntax, you don't actually need to use it... you only need quicktemplate if the page isn't going to be dynamic [17:14:54] gwicke: But mustache does santization. [17:14:59] * brion agrees with subbu [17:15:01] csteipp, nope [17:15:06] only html sanitization [17:15:12] no attribute sanitization [17:15:17] see the first paragraph [17:15:21] wtf? I don't usually misread that badly. need to get my eyes checked [17:15:22] My Yet Another DSL concerns are more along the lines of "why use an existing language when I can INVENT A NEW ONE and have fun!!1! ... and have bugs in my parser because I'm not reusing established well-tested code" [17:15:53] so let's talk a bit about the knockout syntax then, seems like at least a couple of people are concerned [17:15:58] I'm not sure if it's a DSL [17:16:05] it's json + js expressions where needed [17:16:07] gwicke: Right, but performance-wise, the regexes they are doing are expensive.. does your code do any simple santization? [17:16:23] csteipp, it does simple html escaping as in mustache [17:16:34] Ok cool, I missed that in the code [17:16:34] but no attribute sanitization (protocol filtering etc) [17:16:51] So can you post numbers with this? [17:16:53] mwalker, I might not be up to date with everything, what's quicktemplate? do we have out own JS templating system? [17:17:01] cscott, sure [17:17:04] also, does anyone still remeber that we're supposed to have a library portable between JS and PHP? [17:17:08] *quicktemplate being the current working name for the intermediate language processor [17:17:17] MaxSem, good point [17:17:34] cscott, for now, between about even with handlebars and 30% or so faster [17:17:43] eh, csteipp [17:17:52] I was under the impression that the current proposal also works in PHP, is that not the case? [17:17:53] * gwicke curses at xchat's completion [17:17:54] MaxSem, yep; right now it's js only, but I don't expect the port to php to be difficult or all that involved; it's some 200 lines of JS [17:18:03] milimetric, mwalker is there any wiki page about it? any repo? [17:18:20] i can find some examples of quick template, one sec [17:18:20] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal [17:18:38] gwicke: Actual numbers in different scenarios would be really nice to see :) [17:18:39] mwalker, DOM manipulations are native to JS, however they all suck in PHP [17:18:40] milimetric, I searched for "quicktemplate" on that page, 0 results [17:19:01] right, it's just what gwicke's calling it, don't think it shows up on that page [17:19:02] DOM isn't that awful in PHP. it's just verbose ;) [17:19:09] csteipp, will post those after re-running it- but don't take my word for it ;) [17:19:24] and by it I mean the intermediate language processor that takes knockout templates to the IR [17:19:28] * MaxSem refers brion to HtmlFormatter and its horrors [17:19:28] jgonera, it's hidden in a note: https://github.com/gwicke/TemplatePerf/tree/master/QuickTemplate is the code [17:19:29] jgonera, https://github.com/gwicke/TemplatePerf/tree/master/QuickTemplate [17:19:41] thanks [17:19:50] this is an old signup form using a QuickTemplate class: [17:19:51] https://github.com/Wikia/app/blob/dev/extensions/wikia/SpecialSignup/templates/Signup.php [17:19:59] Isn't it also slower in php? [17:20:02] MaxSem: DOM manipulation is native in *browser* JS, it also sucks performance-wise in nodejs [17:20:03] should we #action something about stats? [17:20:05] so far this is the result of about two days [17:20:20] it has an execute() function and then jumps into raw PHP. it's pretty ugly. [17:20:22] like RoanKattouw, I'm pretty skeptical of new shiny. if we do something new, we should make sure what we do becomes ubiquitous rather than having *yet* *another* weird MediaWiki-specific way of doing things. [17:20:27] ugh, so that's basically writing HTML in JSON? [17:20:30] TrevorParscal: Log of discussion so far http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140221.txt ; proposal we're discussing (read this first): https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal [17:20:32] gwicke, ^ [17:20:46] jgonera, you mean the JSON IR? [17:20:52] that's a compilation target [17:20:55] IR? [17:21:01] intermediate representation [17:21:01] intermediate representation [17:21:04] right [17:21:08] i think the QuickTemplate that gwicke is talking about is totally different. so, i was a bit confused. :) [17:21:15] but someone said that I can just use this if I don't want knockout [17:21:17] you can write it manually too if you feel like it [17:21:18] yes OwynD_ [17:21:36] mwalker said that [17:21:45] OwynD_, ya... sorry --- our quicktemplate is a string based json ir to html library -- we couldn't come up with a better name last night to avoid confusions... [17:21:49] OwynD_, sorry for the confusing working name [17:21:56] gwicke: This may be in the RFC and I may have missed it: is there or will there be code that translates the JSON IR to straight up non-Knockout HTML? [17:22:00] no problem, all cleared up now. [17:22:00] Knockout.JS -- (compiled by quickTemplate) --> IR ... i doubt anyone would write IR directly, that is like writing assembly. [17:22:03] yeah, mwalker/gwicke, are you envisioning people writing directly in IR if they want? [17:22:05] yes, but the thing is I don't think anyone would feel like writing the IR, gwicke, mwalker ;) so it is either knockout or nothing [17:22:06] spent about two seconds thinking about a name.. [17:22:22] sorry, not knockout.js but knockout.js templats [17:22:24] RoanKattouw, normally you'd want to do the reverse [17:22:29] that's what's implemented [17:22:38] Well on the server side, yes [17:22:45] I have a template, I precompile it to JSON IR [17:22:47] jgonera, yesish; it's KO syntax to JSON IR, and then use the quicktemplate stuff to render it (I was pointing out that you don't need the 16kb of KO.js if you don't need it on the page) [17:22:48] but converting from JSON IR to knockout should be feasible too [17:22:50] JSON IR is delivered to the client [17:22:59] Client does ??? , stuff appears on the user's screen [17:23:11] I assume ??? == "render JSON IR to plain HTML" in this case? [17:23:16] RoanKattouw, yes [17:23:22] OK sweet [17:23:43] So can one of you expand on template inclusion? From a reviewer perspective, that looks like it could be a lot of work if you have templates full of template references. Does the entire
get substituted in your example? [17:23:49] in the server-side use case loading the pre-compiled JSON from memcached and interpreting it should be pretty fast [17:23:51] Just making sure we wouldn't be locked into any Knockout overhead on the client, even for places where we use it as a server-side templating language [17:24:03] much faster than DOM-based templating [17:24:15] while still providing the same guarantees re nesting and sanitization [17:24:52] there was work done a few years ago to bring wikitext i18n messages to the client in a sort of JSON IR, are you guys aware of that? [17:25:04] csteipp, I believe the div becomes a parent element of the included template [17:25:07] TrevorParscal, ohh, interesting ;) [17:25:13] I didn't know about that [17:25:17] this is how we do complex client "parsing" for gender and stuff [17:25:18] we are reinventing the wheel then [17:25:19] TrevorParscal: By Neil K, I think? [17:25:22] yes mwalker, that's right about inclusion [17:25:31] Yeah and doesn't the PLURAL/GENDER stuff in mw.jqueryMsg or whatever it is use this [17:25:32] yes, Neil [17:25:32] yeah i recall that being used for uploadwizard [17:25:56] i'm not saying it's as complete as this system, but just something to be aware of [17:26:10] the beauty of a low-level IR is that you can compile different syntaxes to it [17:26:17] gwicke, I'm not exactly sure what is the purpose of the IR [17:26:18] as far as I know there is no IR that is being transmitted from server to client for i18n, just the wikitext [17:26:19] one syntax is wikitext, with the help of parsoid [17:26:21] as I recall, it actually did prove very efficient despite some initial skepticism [17:26:37] csteipp, I'm not sure of how to avoid the template inclusion rats nest issue -- but if we're autoescaping things; what's your concern? [17:27:05] jgonera, the purpose of the IR is to have a very efficient and small interpreter / runtime [17:27:05] the point of IR should be to spare the client the complex part of the process, which is parsing [17:27:09] Hmm it might be that the message stuff is a local parser that parses wikitext into an IR on the client, rather than sending precompiled IR over the network [17:27:14] jgonera, the point of the IR is so that we can have a nice safe DOM based templating language that's slow to compile; but then string based on render which is really fast [17:27:21] Which as Trevor just beat me to saying, is missing the point of an IR [17:27:24] RoanKattouw: that [17:27:47] gwicke, mwalker but why if nobody will want to write IR by hand anyway? [17:27:57] the IR should make it possible to take immediate action, not have to lookup data in the database and be in a high-performance format (JSON qualifies) [17:28:03] jgonera, that's what compilers are for [17:28:13] jgonera: Execution of DOM modification is slow in environments that aren't browsers [17:28:17] Including nodejs [17:28:34] So being able to do manipulation on a JSON structure that's equivalent, then rendering it to HTML at the end is faster [17:28:34] mwalker: If it's appending the included elements into the parent, then that should be fine. I'm assuming the template has to be valid xml, so someone can't do
[17:28:40] RoanKattouw, any particular use cases we are talking about? [17:28:56] jgonera: Someone writes a Knockout template on the server [17:28:56] I believe in the general approach to doing the parsing on the server, and the dom building on the client [17:28:57] csteipp, yes; part of the final compiler will be to ensure that templates are well formed [17:28:58] I mean, do we even know what we want to use the client-side templating for? [17:29:00] csteipp, that's covered by attribute sanitization [17:29:08] Or in a wikitext template or whatever [17:29:15] there is an attr binding that produces dynamic attributes [17:29:19] Server precompiles to JSON IR, sends to client, client renders to HTML [17:29:24] we can do any kind of sanitization in there [17:29:34] also, the JSON IR can be cached [17:29:38] of course [17:29:42] csteipp, https://github.com/gwicke/TemplatePerf/blob/master/QuickTemplate/quicktemplate.js#L102 [17:29:45] jgonera: I want to use to separate html layout from logic [17:29:57] RoanKattouw, don't we lose all the benefits of Knockout (dynamic data binding) if we write in on the server? [17:29:58] flow also uses it to do rerendering of message boards [17:30:25] Nikerabbit, that's obvious, but I'm asking about specific examples where performance would be such a huge concern [17:30:26] jgonera: If you want those benefits you need to write things on the client, is my understanding [17:30:28] there's always some logic in the layout. if you have an optional button, it's logic... [17:30:37] This is just a way to use Knockout as a non-dynamic templating language [17:30:38] jgonera, yesish; server side rendering will not be dynamic -- it'll get you a static page that you can then attach KO to on the client [17:30:45] jgonera, https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture has a path for that if i udnerstand corectly [17:30:50] Which sounds stupid but is apparently the fastest way they found to do server-side templating [17:31:02] jgonera, and https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Server-side_pre-rendering [17:31:15] (while using the same template format across the board) [17:31:31] yeah, jgonera, that last point by RoanKattouw is the basic motivation for all this [17:31:32] we can do server-side pre-rendering, but leave the knockout data in the DOM [17:31:42] client-side things can then be updated dynamically [17:32:08] i do like that [17:32:14] a small point about this dynamic client side behavior [17:32:21] the knockout attribute syntax actually helps with that [17:32:23] ability to start with filled-out data (for fast load and non-JS users) and then let JS update things live [17:32:27] it's not completely trivial to include a template dynamically and then have it start updating [17:32:34] as you can keep it in the DOM without breaking the rendering [17:32:39] it's also valid HTML5 [17:32:43] you have to tell knockout about it and whether you want to control the bindings in the child template or it should do it for you [17:32:49] but that can be genericised [17:33:03] i think baking data in makes caching less useful [17:33:07] I think this answers one of Nikerabbit's points on the RFC proposal discussion page [17:33:12] milimetric, yes that's true... but everything we looked at indicated it wouldn't be hard to make something to do that for us [17:33:19] there are some solvable issues in the pre-rendering area: https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#cite_note-3 [17:33:32] i've built that a few times mwalker, one way to do it is a simple custom binding, about 10 lines [17:33:59] milimetric, can you add a reference to that somewhere on our wiki page? [17:34:03] TrevorParscal, it is a trade-off [17:34:07] sure, but it's in coco :P [17:34:16] pre-rendering does not make sense for everything [17:34:30] sure, but it's a practice that can get you into trouble if you aren't drawing the line carefully enough [17:34:50] milimetric, heh; might still be useful [17:34:57] it is a possibility though, and we could make it easy to choose whether things should only run on the server, only on the client or on both server & client [17:35:03] i think figuring out what you want the end result to look like comes before performance considerations. you can make "most" things fast, one way or another. :) [17:35:17] once you make something ugly, you're stuck with it [17:35:33] OwynD_, agreed [17:35:42] anybody up to trying a branch of their ext or core bit using this sort of system, see how it works in real life? [17:36:07] we've been looking for a templating solution in flow, but php is a must [17:36:14] brion, I have a couple of fundraising extensions [17:36:21] I'm willing to try this as well [17:36:28] great [17:36:29] yeah, i think one good experiment would be to convert a really simple extension with both js and PHP components to using this system. [17:36:30] OwynD_, yes .. to repeat an earlier qn: one question to address would be how much peak performance weighs into decision of a templating system vs. syntax and other desirables [17:36:30] it is fairly straightforward to define a subset of the knockout syntax, and even enforce that in knockout by modifying the expression parser slightly [17:36:37] premature optimization is evil, but considering caching and basic performance characteristics of server and client is a reasonable thing to do [17:36:39] but for that I need more concrete ideas how this integrates with mediawiki (as I pointed out in the talk page) [17:36:42] OwynD_, agreed [17:36:52] OwynD_: +1 about using this thing [17:36:58] something non-trivial [17:37:03] #idea yeah, i think one good experiment would be to convert a really simple extension with both js and PHP components to using this system. [17:37:04] OwynD_, the JSON IR decouples syntax & performance somewhat [17:37:11] gwicke: is the PHP side still all theory or any work on that yet? [17:37:15] mwalker: https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/HTML_templating_library/KnockoutProposal/General_thoughts/reply [17:37:32] brion, all theory right now, but porting ~600 lines of js total should not be that hard [17:37:37] spiff [17:37:37] I really appreciate all the effort put into this, but I'm a bit afraid we are overengineering things for our current needs [17:37:37] the runtime is only 260 lines [17:37:45] who wants to commit to setting that up? [17:37:51] that's on my plate [17:38:06] It's important to actually use this in something non-trivial, it will evolve quickly - OOJS and OOJS-UI area both products of necessity, we need them, and that is what makes them useful - they actually solve problems [17:38:29] jgonera: it doesn't feel too big to me; it feels just flexible enough to solve known issues [17:38:33] I'm concerned about this being used for UI, but that's another RFC I guess [17:38:35] but not *too* flexible to be crazy [17:38:36] i think that will really help. may be a simple caveman developer, but it's hard to evaluate this without seeing a bigger example. [17:38:44] so what specifically is the #action for mwalker? :) converting an extension to use the proposed sys? [17:38:56] so my instinct re syntax is to start with a really restricted subset [17:38:59] TrevorParscal: what do you mean with that? [17:39:06] sumanah, my action is to port the JS IR compiler / runtime to PHP [17:39:11] basically only dot notation and literals [17:39:15] #action mwalker sumanah, my action is to port the JS IR compiler / runtime to PHP [17:39:34] UI shouldn't be using widget libraries, that's what I mean - not trying to derail this convo, but I'm really serious about that [17:39:55] Trevor: that was kind of my earlier point at the summit... i think it might be difficult to get 1 solution that works for both content and UI. they're different domains, different type of user. (content authors vs developers) [17:39:58] sorry, SHOULD be using [17:40:09] :) [17:40:12] i was gonna say TrevorParscal [17:40:23] ok, any more #agreed decisions or #action items before we wrap up today's HTML templating discussion and move on to the next topic? [17:40:33] brion: ^ [17:40:34] OwynD_: yeah, content and UI are quite different, they need different tools [17:40:37] gwicke: ^ [17:40:51] i think we're about good for now [17:40:58] I'd say that seeing this in action in a specific use case should also be an action item [17:41:03] go ahead jgonera [17:41:08] mark it [17:41:13] #action mwalker Answer Nikerabbit's questions about RL integration [17:41:15] I think what knockout could potentially give us is a standard templating approach to wrap around a widget library [17:41:28] #action seeing this in action in a specific use case [17:41:48] who'll be doing that? [17:42:07] I am also curious to heard about potential use cases for reactivity [17:42:11] *hear [17:42:20] I'm afraid I have too much on my plate in the nearest couple of weeks... [17:42:26] sumanah, presumably either gabriel or myself [17:42:36] i like the idea of a generic system in core that allows people to build reusable widgets/ui components, in extensions and even in user land (like gadgets, etc) [17:42:41] for something not in the mediawiki universe but close, you can check out wikimetrics's use of knockout and reactivity [17:43:04] milimetric: *nod* [17:43:13] #action gwicke or mwalker to demonstrate this in action in a specific use case ("this" being mwalker's port?) [17:43:30] ok, we basically done here? I'm about to switch topic to Services and narrow interfaces [17:43:56] ideally I'd like to partner with a real project [17:44:16] so if anybody has a small but real project with templating needs coming up, let us know [17:44:17] do we have time for SoA? [17:44:24] i can dedicate some of my volunteer time to help someone implement this in a real project [17:44:26] gwicke, what's the timeline? how soon do you want to do it? [17:44:28] * MaxSem doubts this [17:44:43] jgonera, with ~1 month? [17:44:46] but I have no mediawiki extension experience, so preferably it'd be someone with an existing extension [17:44:47] within [17:44:49] yeah, i think that sounds like a good place to switch tracks. [17:45:06] alright, lets move on for now [17:45:18] #topic Services and narrow interfaces [17:45:22] gwicke, ok, I'd be interested in trying that out in mobile too then, after I'm done with some other things and possibly when Jon is back and we have more bandwidth [17:45:22] #link https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_interfaces [17:45:26] which is in 1-2 weeks [17:45:29] we have been discussing packaging and distribution recently [17:45:53] sumanah: We *really* need the topic to note the logging, per Legal. [17:45:57] jgonera: ok, cool [17:46:15] parsoid now has a debian package [17:46:22] \o/ package ftw [17:46:29] which is published only in a labs repository so far [17:46:44] Thanks. [17:46:51] (Missed one when converting to pipe-separation, sorry) [17:47:09] James_F: I'll take that out of this mtg and talk with Tim L about our meetbot install or something, thx [17:47:10] so one thing we are looking for is a longer-term apt repository for third party users [17:47:18] sumanah: Sure. [17:47:21] #action sumanah to work on topic including "Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours" - talk with Tim L [17:47:25] so we've got some sort of apt repository we have our custom packages in.... do we need a separate one for public-targeted packages? [17:47:33] yeah, that'd be best [17:47:34] the second point is an automated procedure to upload debs to that repository without root [17:47:50] so, I'll explain that, as soon as gwicke is done [17:48:09] Small note, guys: There's an office hour immediately after this [17:48:24] the third aspect is potentially using packages for service deployments [17:48:25] Which maybe would have been more evident had there been an entry in https://meta.wikimedia.org/wiki/IRC_office_hours about this meeting [17:48:28] But alas [17:48:33] thx rdwrer - will fix that for future [17:48:39] live and learn :) [17:49:07] gwicke: so what needs to be planned for? [17:49:28] I don't think we can discuss all these issues in 10' [17:49:43] yeah, we might only get partway through [17:49:45] let's focus on third-party distribution for now, since that's easier? [17:49:54] okay, one thing about this particular draft proposal... it's similar to the discussions we had a few months ago about an API 2.0 [17:50:02] or should we just discuss packaging? [17:50:16] let's stick to packaging since we're short on time [17:50:21] OwynD_, this is just about packaging & distribution [17:50:40] right [17:50:43] paravoid, the decision on 3) will change the best solution for the repo [17:51:01] or rather, might [17:51:05] there's no way we're gonna reach a decision on 3) today :) [17:51:12] especially since there's no prototype for it [17:51:20] it could be feasible to start with a public repo for now [17:51:34] #link https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Services_and_narrow_interfaces - please do talk on the talkpage after this meeting :) -- hasn't been talked on since 3 January [17:51:35] and if we move to deb deploys automatically dput to that repo too [17:51:35] I think that providing up-to-date packages for mediawiki & "mediawiki services" would do a great service to our users [17:51:38] (nit: is the third point of packages as deploy for services the need that the second point is helping? ie: without the 3rd, is there still a need for gwicke's second point?) [17:51:41] in addition to an internal repo [17:51:57] distributions' release schedules, even the aggressive ones, tend to have different priorities than we do [17:52:06] so a model similar to http://mozilla.debian.net/ would be great, I think [17:52:25] yes i def agree we should have a public repo that's easy to add to a debian or ubuntu system [17:52:33] great [17:52:37] #agreed yes i def agree we should have a public repo that's easy to add to a debian or ubuntu system [17:52:41] on the matter of reusing apt.wm.org [17:52:53] apt.wm.org is implicitly trusted across the wikimedia infrastructure [17:53:19] Could we just used a PPA as an external deb publication point? [17:53:20] there are all kinds to attack vectors by opening access rights to that outside of a very strict set of users [17:53:21] we'd need that for deploys, but not necessarily for third party use [17:53:35] additionally, apt is not great at having multiple versions of the same package around [17:53:35] *use a PPA [17:53:45] PPA works well for ubuntu; is that still easy to use on debian? [17:53:46] paravoid, why's that? [17:53:58] because you can't easily pin a "branch" or a "train" [17:54:02] paravoid, I thought that's mainly a limitation of reprepo [17:54:02] newer versions win [17:54:24] it's definitely a limitation of reprepro, but think of the simpler way of having to support e.g. mediawiki 1.21 and 1.20 [17:54:25] you can hold a package [17:54:36] and users wanting point releases (security update) for 1.20, but sticking to 1.20 [17:54:41] it won't be upgraded automatically then [17:54:49] there's no way you can do this with multiple versions in apt [17:54:52] so in the example I gave above [17:54:55] http://mozilla.debian.net/ [17:55:14] brion: "On debian 7 the add-apt-repository command is available and can be used to add any launchpad ppa repository in a single command." -- http://www.binarytides.com/add-ubuntu-ppa-repository-to-debian-7-wheezy/ [17:55:16] you can see how multiple branches are maintained: using different suites [17:55:23] nice [17:55:50] paravoid, major versions / branches can also be handled with different package names [17:56:00] nah, that's really ugly [17:56:04] similar to python etc [17:56:22] you want people to do "apt-get upgrade" and get the latest version for the release train they've picked, I think [17:56:26] I haven't spent much time thinking of it, though [17:56:26] it is a common solution, and it does work [17:56:42] ok we're running low on time [17:56:50] what do we need to decide to talk further about? [17:56:51] my idea was to use a format like the mozilla.d.n, but under the releases.wikimedia.org host [17:56:54] Apparently hashar has even registered https://launchpad.net/mediawiki [17:57:05] ooh i like using releases.wm.o [17:57:19] I plus 1 the mozilla.debian idea, instead of the python pakage versioning insanity (all parties have a hard time with that) [17:57:29] I think it would be great to start with a public repo that supports multiple versions per package [17:57:40] and provide different components and suites for mediawiki, parsoid etc. and different branches of them [17:57:51] with a script to push to it from tin or the like [17:57:55] and allow uploads from the respective developers of each team [17:57:59] instead of just ops [17:58:15] or a direct dput setup [17:58:31] #info PPA is a possibility; as is running a repo on releases.wikimedia.org. versioning still an issue to discuss [17:58:34] yup, dput and proper archive would be geat too, if developers can endure that :) [17:58:44] *great [17:58:57] great :D [17:59:03] can you guys add some notes on the talk page? [17:59:05] and we'll wrap up [17:59:08] "uploads to components based on team membership"++ [17:59:08] scap has proven that developers can endure anything [17:59:13] #action notes to talk page... [17:59:28] I should say, gwicke has been driving and pushing this, so credit belongs to him [17:59:45] I'm just giving my opinion, based on my experience/background [17:59:46] #info next meeting, MaxSem to talk about inline diffs [17:59:51] sumanah: ok iirc we have to wrap up for the office hours in here now? [17:59:52] Antoine has also been very active [17:59:53] #endmeeting [17:59:54] Meeting ended Fri Feb 21 17:59:53 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [17:59:54] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-21-16.58.html [17:59:54] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-21-16.58.txt [17:59:54] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-21-16.58.wiki [17:59:54] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-21-16.58.log.html [17:59:57] \o/ [18:00:04] thanks everybody! [18:00:08] thanks, everyone. this was pretty interesting. [18:00:12] Next up on #wikimedia-office, the Multimedia team talks about their projects! [18:00:12] thanks! [18:00:18] paravoid, I'd rather stomach debian packaging than puppet :p [18:00:19] Wooplanning [18:00:22] thanks everybody! [18:00:41] we can discuss more in another channel if you want [18:00:50] All right [18:00:57] Officially co-opting the channel now [18:01:01] #startmeeting [18:01:01] #meetingtopic Media Viewer v0.2 and other multimedia projects [18:01:01] #chair fabriceflorin tgr aarcos gi11es [18:01:01] #topic Media Viewer vision and purpose [18:01:01] #link https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer [18:01:01] rdwrer: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' [18:01:05] Bah [18:01:15] #startmeeting Media Viewer v0.2 and other multimedia projects [18:01:16] #chair fabriceflorin tgr aarcos gi11es [18:01:16] #topic Media Viewer vision and purpose [18:01:16] #link https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer [18:01:16] Meeting started Fri Feb 21 18:01:15 2014 UTC and is due to finish in 60 minutes. The chair is rdwrer. Information about MeetBot at http://wiki.debian.org/MeetBot. [18:01:16] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [18:01:16] The meeting name has been set to 'media_viewer_v0_2_and_other_multimedia_projects' [18:01:16] Warning: Nick not in channel: tgr [18:01:16] Warning: Nick not in channel: aarcos [18:01:16] Current chairs: aarcos fabriceflorin gi11es rdwrer tgr [18:01:25] rdwrer: Don't forget to fix the /topic [18:01:29] (re public logging) [18:01:34] FFS. [18:02:11] * rdwrer looks at fabriceflorin [18:02:21] Let's talk about media! [18:02:24] Hi folks, welcome to our IRC Chat about Media Viewer. [18:02:34] Who all is here to talk about multimedia? [18:02:36] gwicke: is the convo going somewhere else? or shall I stop looking in various channels? :) [18:02:59] fabriceflorin: I'm here :) [18:03:08] woo multimedia! [18:03:22] Double meeting feature! [18:03:23] Today's focus is going to be on the Media Viewer, which our multimedia team has been developing in recent months. Learn more here: [18:03:30] https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer [18:03:46] Hey brion and bawolff, so glad you're both here :) [18:03:47] greg-g, I'm in #wikimedia-dev if anybody want to continue the discussion [18:03:58] Anyone else joining us for the Media Viewer chat? [18:04:15] OK, let's get started then. [18:04:32] Hi, I’m Fabrice, multimedia product manager at Wikimedia Foundation, and I will be hosting this discussion along with our team members … [18:04:43] gi11es is our senior software engineer, rdwrer is front-end engineer, tgr is back-end engineer, pginer is our designer and Keegan is community liaison [18:04:55] Please say hello to our wonderful multimedia team :) [18:05:15] Hi team! [18:05:21] Hello, team. [18:05:28] * chrismcmahon1 lurks for the MMV discussion [18:05:44] Hi rillke, so happy to see you again! Hope all is well with you ... [18:06:01] Hey DarTar, thanks for joining our conversation about Media Viewer :) [18:06:28] Today, we would like to discuss new features for this multimedia browser, which we developed based on feedback from community and team members like you. Here’s what we’re working on now: faster image load, better user interface, more meta-data, attribution and permissions -- and an improved ‘use this file’ tool with share, embed and download options. [18:06:42] awesome [18:06:51] For a quick overview of Media Viewer, check out this page: [18:06:52] https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer [18:07:26] We also invite you to participate in our ongoing discussion about Media Viewer here: [18:07:27] https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer [18:08:11] And for a glimpse of the underlying vision behind Media Viewer, we have a cool video here on Commons: https://commons.wikimedia.org/wiki/Commons_talk:Multimedia_Features/Vision_2016 [18:08:47] Sorry, here's the video page: https://commons.wikimedia.org/wiki/Commons:Multimedia_Features/Vision_2016 [18:09:00] #link https://commons.wikimedia.org/wiki/Commons:Multimedia_Features/Vision_2016 [18:09:14] So the basic purpose of Media Viewer is to improve the viewing experience for all users, so they can see images in large size, the way they were meant to be seen ... [18:10:07] But this new multimedia layer also gives us an opportunity to engage users to use the files in different ways, so they become part of our multimedia ecosystem as active contributors. [18:10:43] So we are hopeful that over time this simple feature can make a big difference in helping our community share media-rich content that can help us all learn in better ways. [18:11:02] So that's the big picture. Now let's dive in to the new features. [18:11:45] #topic Media Viewer 0.2 status [18:11:57] Mark , er rdwrer , would you like to give us an overview of what you've been working on lately? Maybe point folks to a demo where they can see your new features? [18:12:09] Sure! [18:12:34] Let's see. The team has indeed been focusing on a much snappier load of images, that's been a huge priority in the past few weeks. [18:12:59] We've also been working on nicer-looking interfaces and pulling more important stuff into the before-the-fold bits of the interface [18:13:37] I don't suppose there'd be a way to more clearly distinguish "date of file creation" from "date of file upload" ? [18:13:41] because that's been a serious problem./ [18:13:43] And last but certainly not least, adding more information - the media viewer now shows you file usage and categories, and fun things like assessments (POTY, POTM, etc.) are on the way [18:14:02] Dragonfly6-7: "yes" - we have a message for each and prefer creation, show upload if creation is not present. [18:14:03] Hey jfelipe Revi alantz OwynD : welcome to our chat about Media Viewer, which you can learn more about here: https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer [18:14:22] Or I think that's how we do it. [18:14:31] * rdwrer is second-guessing [18:14:31] fabriceflorin: in regards to "But this new multimedia layer also gives us an opportunity to engage users to use the files in different ways, so they become part of our multimedia ecosystem as active contributors" - what exactly does that mean [18:14:37] thanks fabriceflorin [18:14:40] Nope, I was right [18:14:49] rdwrer: so what's being done to have much snappier loading of images? [18:15:17] bawolff, good question, sounds too abstact for me, too [18:15:25] mark: Mostly stuff on the frontend - tackling the thumbnailing systems will be a much bigger task. [18:15:42] mark: preloading next and previous image, fullscreen image (if different) [18:15:45] mark: We bucket image thumbnail requests into a set of predefined sizes, for example [18:15:48] And that. [18:16:15] mark: We're also looking into putting the thumbnail into the interface first, blurred, so the screen isn't totally blank. [18:16:26] I see... thanks [18:16:32] mark: Mostly it's perception, not backend performance improvements :) [18:16:38] also visual tricks to make things feel snappier [18:16:50] rdwrer: re: blurring, not a bad idea [18:16:59] backend improvements are pending works from ops, the discussion has happened with paravoid [18:17:03] Keegan: We go back and forth on it, but I think we've settled. [18:17:12] bawolff: We think the new 'use this file' tool which rdwrer is working on can make it much easier for people to reuse media in a variety of ways, and makes these features more prominent, right on the site where you are viewing the content. Here are some specs and screenshots about this awesome tool: https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer#New_Tools [18:17:16] Sure. It's a take it or leave it [18:17:18] rdwrer: Arguably you are increasing cache hit rate, so that will help back end servers [18:17:27] bawolff: Ideally! [18:17:41] #link http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo [18:17:54] Hey gi11es, do you have a link to the video you made to show how the blurred thumbnail can effectively cover image load? [18:17:58] That's a labs instance that has the viewer enabled by default for everyone (even logged-out), so it's my go-to choice for demos [18:18:13] fabriceflorin: I'll dig it up [18:18:31] It doesn't have a few brand-spankin'-new features, but it has a work in progress version of the new file reuse panel [18:18:55] You can find that in the bottom right corner of the lightbox when you open it [18:19:09] I don't think new features matter near as much as making things like reuse and download more fluid [18:19:29] Keegan: Indeed - which is why we're working on that this week and next. :) [18:19:32] When I see a current file page, I feel like I'm looking at one of those horrible free upload sites :) [18:19:33] (excuse the non-free format) this is a screencap I recorded when we were prototyping the blurry thumbnail + progress bar https://dl.dropboxusercontent.com/u/109867/Blurry%20thumbnail%20%2B%20progress%20bar%20prototype.mov [18:19:55] So many boxes! [18:19:56] Thanks, Gilles! BTW, this is a good opportunity to introduce gi11es, our senior engineer and latest team member, who joins us from France, where he worked at DeviantArts. In a moment, he can tell us a bit more about his background and what he hopes to accomplish here at with our multimedia team. [18:20:00] the real deal is a changeset currently in review, so we should be to see it in action in a few days [18:20:13] Not sure if this is too technical a question given the intended demographic of this office hours, but what sort of ops work are you considering to improve file render time? (And are there notes to that somewhere on wiki?) [18:20:21] http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo [18:20:36] bawolff: the plan is to prerender the thumbnail buckets at upload time [18:20:43] Also, we did some fun work on making the modules for the extension not load until needed, and have been working on technical debt, making the codebase easier to work with and contribute to. [18:20:50] the blocker right now is capacity and the fact that we keep all thumbnails forever in storage [18:20:55] I think that's all I've got [18:21:12] There are maybe other things I'm missing but fabriceflorin didn't warn me I'd need to talk about this. :) [18:21:15] gi11es: Oh, I was hoping that you would find some magic way to render them on demand instantly :P [18:22:04] Thanks, rdwrer, really appreciate this overview. gi11es, as our new team member, want to give us a bit of background on who you are, what you are working on and plan to accomplish with Media Viewer? [18:23:04] I joined the WMF in January. I used to work at deviantART, where I've worked on very similar projects (media display, upload, etc.) [18:23:16] so you're a professional deviant? [18:23:25] Dragonfly6-7: Yeah, he fits right in [18:23:52] gi11es: You surely should have chosen another user name in the video. [18:25:10] Hey Deskana, mindspillage, Dragonfly6-7, ppena : thanks for joining our chat about Media Viewer. We're discussing some of the new features described here: https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer#New_Tools [18:26:05] rdwrer: Could you give us a bit more info on the 'Use this file' tool you're working on? A quick overview of the Share, Embed and Download functions? [18:26:18] I mean, sure, briefly [18:26:31] rillke: I thought I was recording this for an audience of 2-3 people, so didn't bother changing my local install's username, etc. had I known it'd be shared today, I would have switched :) [18:26:48] The panel uses the new oojs-ui library that the VE team was working on, which has been a fun experience [18:27:14] Here's a screenshot of the Embed tool, based on a design by pginer : https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer#mediaviewer/File:Media Viewer embed.png [18:27:28] We're implementing the three choices for how to reuse a file - share, which basically just means linking someone to it; embed, which means putting it in a wiki page or HTML page somewhere; and download, which is what you'd expect [18:27:57] You can see an early alpha version of the Share and Embed tools on this prototype site: http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo [18:28:02] We get the fun task of sorting out all of the resizing and thumbnailing and URL options for you on the backend of this feature, which is causing us some small amount of grief, but the interface is looking purty [18:28:30] Our hope is that by making the Use this File tool more prominent right below the image, this will encourage more folks to make use of the amazing content that's on Commons :) [18:29:47] fabriceflorin - we also need to encourage folks to read the reuse terms [18:29:48] So stay tuned for a shiny new 'Use this file' tool, coming in a few weeks to a screen near you :) Please let us know how we can improve it on this discussion page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer [18:30:04] I've seen far too many pictures on other websites credited to "Wikimedia Commons", with no further details [18:30:06] Dragonfly6-7: We have links to the authour, source, and license in the default attribution strings for both formats. [18:30:22] We can't stop people from changing it, but it's there. :) [18:30:27] Oh wait, no, only for HTML. [18:30:39] We've changed that decision a lot this week. :) [18:31:04] tgr: Would you like to tell us a bit about what you have been working on? We'd love to hear about new improvements you are making to show more attributions, license info and permissions, so people know how to use the files. [18:31:10] fabriceflorin: I'm not seeing a share and embed tool on the link you gave [18:31:30] err never mind [18:31:34] bawolff: The bottom-right corner of the main lightbox view, the top-right corner of the metadata panel [18:31:36] clicked on the wrong link [18:31:37] Oh, 'kay [18:31:41] * bawolff hangs head [18:31:47] No worries! [18:32:04] So where does the "share" section go [18:32:16] hi all [18:32:19] As in, does it go to facebook [18:32:20] bawolff: It's just a link to the description page [18:32:31] We don't have any integration with any sites yet [18:32:37] Dragonfly6-7: I couldn't agree more with you. That's why we're working extra hard to make sure that all required attributions are prominently included in both the Embed and Download features, in addition to displaying them in the Media Viewer itself. For example, take a look at this gory spec: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/148 [18:32:53] bawolff: We're cognisant of the controversy we'd have to deal with :) we'll address that when we have to. [18:33:00] * sumanah looks forward to Use This File tool! just wanted it today [18:33:03] we have been developing a new API to get image details based on the description page templates, such as author name, license, description [18:33:15] rdwrer: That was why I was asking :) [18:33:16] you can find the details at https://www.mediawiki.org/wiki/Extension:CommonsMetadata [18:33:22] sumanah: It exists in the current version in a different form [18:33:31] And here's the spec for the new and improved Download tool -- can't wait to use these tools: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/79 [18:33:41] There's a link in the metadata panel that opens a dialog [18:33:46] But ew, jquery.dialog [18:33:49] Who wants that [18:33:53] So we're making it more better. [18:33:59] (hat tip to bawolff who wrote the first version) [18:34:15] * rdwrer applauds bawolff [18:34:17] * bawolff didn't do all that much :) [18:34:32] Sorry, tar, didn't mean to interrupt you. Please go on about the fine work you are doing with CommonsMetadata (which was initially started by the one and only bawolff - go team!) [18:34:33] you guys have taken it much further since then [18:34:36] it is intended to be a temporary measure until Commons gets something like Wikidata [18:36:14] so in the current version of the MultimediaViewer you can see who was the author of the work, when it was created, on what pages it is used, what kind of license it has [18:36:44] sumanah: Glad you like the new 'User this file' tool design from pginer -- I think improving the UI will go a long way towards making these features usable by people who are not so tech-savvy. [18:37:32] in a week or two, it will display extra permissions (based on the Information template), file assessments (featured image, POTD in 2012 etc) [18:39:05] hi all, is the multimedia office hour still going on? [18:39:11] dschwen: yes [18:39:13] Technically [18:39:15] dschwen: That's what the topic says! :) [18:39:20] :-) [18:39:30] Thanks, tar: Here is a screnshot that shows the new Meta-Data panel for Media Viewer: https://www.mediawiki.org/wiki/File:Media_Viewer_-_Metadata-tags_panel-tags.png [18:39:31] Usually these things end up lasting an hour [18:40:05] s/screenshot/mockup/ [18:40:09] Important distinction [18:40:12] something I forgot to mention earlier is that we've started doing detailed network measurement of images and API requests [18:40:34] which should help us monitor the performance really experienced by users [18:40:35] rdwrer: Any plans for where the "more" section is coming from? [18:40:41] The 'See Terms' indicator next to the license info is intended to alert people there are special permissions, and clicking on it would display more permissions info over the image ... [18:41:00] wil the "(Location Icon) from Wikimedia Commons" have functionality? [18:41:17] bawolff: Heh. I'd say "things in this page" or "things in the categories on this file" but it's still up in the air. [18:41:20] * bawolff ideally would love to see it come from Featured/quality/valued images that are in same categories say using dschwen's tool [18:41:25] We may wind up doing some combination. [18:41:26] ... using this type of popup panel: https://commons.wikimedia.org/wiki/File:Media_Viewer_-_Metadata-tags_panel-tags-more.png [18:41:43] dschwen: It already does! [18:41:47] pretty! [18:41:49] oh [18:41:53] dschwen: It links to the file pagfe [18:41:54] page [18:42:14] oh, not to a map? [18:42:28] dschwen: Ohhh I see what you mean, there are two instances of that string [18:42:31] dschwen: Eventually, the Location icon would display the place name, as well as link to info about nearby content, even a wikimap. But we're taking it one step at a time. :) [18:42:31] are there plans to bring video playback into the new viewer too? [18:42:36] dschwen: But same answer - it already does! [18:42:49] dschwen: We have it hooked up to geohack, and it shows the coordinates in the UI [18:42:56] All i18n'd and everything too [18:42:58] nice [18:43:01] That was complicated as all hell to set up [18:43:39] ... so we are putting a lot of work to make sure that key meta-data is included near the image, as well as in the embed and download attributions, so we honor the terms of our contributors ... [18:43:48] brion: yes, video is on the roadmap [18:43:50] Actually on that note (brion's comment) - not to redirect the conversation too much, but what is the status of new kultura library in TMH? [18:44:00] rdwrer: Dschen is a volunteer and created WikiMiniAtlas, I think. [18:44:10] *Dschwen [18:44:12] rillke: I know dschwen :) [18:44:15] bawolff: we've talked to kaltura this week, we're going to share the work on upgrading to kaltura 2.0 [18:44:27] yay [18:44:30] Do you know what the timeframe for that looks like? [18:44:31] the current plan is they upgrade, we review [18:44:38] pginer: Would you like to tell folks about some of the designs you are working on for the next version 0.3 of Media Viewer, as described here? https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer#Next_Version [18:44:46] dschwen: Wow, you just do all the cool things. I had no idea you were behind wikiminiatlas [18:44:55] fabriceflorin: has kaltura committed to a timeline? I don't recall [18:45:05] spiffy [18:45:25] Even just roughly. Are we talking a month, 2 months, 6 months, a year, etc? [18:45:29] rdwrer: just because you said "complicated as all hell to set up" [18:45:40] * bawolff should probably be asking mdale this I suppose [18:45:45] Oh, huh [18:45:47] 'kay [18:46:07] Our hope is to complete a minimum viable product for Version v0.2 in coming weeks (better image load, improved Use this file, more meta-data) and test it on a few pilot sites at the end of the quarter. [18:46:55] Then we would catch up on outstanding bugs, fix or tweak features based on pilot test feedback, before a wider deployment next quarter. [18:47:03] The basic idea of the designs is to provide a design framework where all kinds of media can be supported in a consistent way [18:47:34] fabriceflorin: by wider deployment you mean out of Beta Features and "turned on default" [18:47:39] Once v0.2 is up and running, we would start work on v0.3, with more audio-visual file support, as described now by pginer . [18:48:07] Keegan: Yes, wider deployment would mean turning on Media Viewer by default. [18:48:19] yay [18:48:44] Just clarifying :) [18:48:51] #topic Media Viewer 0.2 release plan [18:48:55] Sigh [18:48:56] the current design is focused on images, video, audio and multipage documents (pdfs, slideshows). on the technical end we aim to make this modular in order to let volunteers easily write a plugin to support a new format [18:49:19] Poor meetbot. S/he's new. [18:49:31] Buggy more like it [18:49:44] fabriceflorin: Are we doing on-by-default for logged-out users, or only logged-in? [18:49:58] gi11es: Our partner Kaltura is still evaluating how long it would take them to integrate their audio-visual player into Media Viewer v0.3, but I expect that it will take a couple months from now to get something up and running. To get ready for this we are starting the design now, even though most of our short-term focus will be on the current version v0.2 [18:51:17] rdwrer: The current goal is to deploy gradually, starting with logged-in users (required to test the beta version), then making it by default for logged-in users, then opening it up to logged out users. This seems like a sensible way to do this, if practical. [18:51:30] 'kay, awesome [18:52:35] So for now, we encourage everyone to help us test the current version v0.2, following these test instructions: https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer#How_can_I_help.3F [18:52:51] I hope its ok to ask a somewhat digressing question - the MP4 rfc is now closed, and the result was negative. Originally there was a comment that video plans would be re-evaluated after the rfc. Have they been? Is there a new plan, or is that to come? [18:53:12] After you've tested, please let us know what you like, what bugs you, and what features are missing on this discussion page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer [18:53:46] bawolff: we've been exploring alternatives, such as partnering with sites like vimeo or youtube to do imports similar to flickr [18:53:53] fabriceflorin: Please only deploying software that works reliably. I am still not using VE because of the first unfortunate impressions I got and I guess it's the same with a lot of fellow users. [18:53:53] We encourage you to bookmark that discussion page, so you can come back to it often. Note that it lists the features that are now ready for testing, separately from the feature that are coming soon ... [18:54:47] bawolff: we would only be importing open formats from them. the discussion with vimeo was very encouraging, they're really motivated to help us in any way they can [18:55:14] rillke: Thanks for your words of wisdom. I'm on your side: I've always been a big fan of careful, gradual releases -- even if other people are sometimes more impatient :) [18:55:17] vimeo supports CC licenses, so in that sense it could be very similar to the way the flickr import works [18:56:16] i'm also spending some research time on fallback Theora/Vorbis players for browsers that would otherwise have been served by MP4 [18:56:26] bawolff: you mentioned dschwen's tool for finding quality images, is that fastcci? [18:56:29] getting encouraging results with JavaScript on newer browsers [18:56:32] tgr: yes [18:56:39] and I've got some avenues to explore with Flash (yes, Flash!) for older browsers [18:56:40] gi11es: Thanks for bringing this up. We're in exploratory discussions with other large multimedia sites about providing a simple way for folks to import CC-BY content in WebM format from large video repositories that support our cause :) [18:57:01] we also have some low-hanging fruit to fix in the existing Java player [18:57:37] for iOS, easiest thing in the medium term is to link out to the VLC app, which is free and open source [18:57:47] (and is based in france so has different patent requirements than us!) [18:58:03] OK, folks, we're approaching the end of our talk. Are there any last important questions we haven't addressed in today's chat? [18:58:36] brion: is the app being preferred over the library because of the patent issues? [18:58:53] We plan to have multimedia chats like these on a monthly basis, but you are welcome to come ring our bell anytime at #wikimedia-multimedia [18:59:01] gi11es: library is a possibility long-term but we'll have to look into legal issues as well as technical ones yes [18:59:20] i.e., make sure we don't ship restricted codecs with our version [18:59:54] Also, we will send regular email updates on our multimedia mailing list. If you are not yet on it, we invite you to subscribe here, so we can stay in touch: https://lists.wikimedia.org/mailman/listinfo/multimedia [18:59:57] right now the build system expects to compile in everything, which we'd have to change [19:00:13] brion: [Slightly off-topic, but you likely know the answer]: If I wanted to see libav we use recompiled to support VP9 and Opus, should I just file an RT ticket, or would there be a better approach for me making that happen [19:00:31] bawolff: probably an RT ticket yeah [19:00:36] CC me on that for reference [19:00:41] * bawolff puts that on his todo list [19:00:58] If you would like to track our progress with all these features, here's our Mingle project management site: http://ur1.ca/gnecv [19:01:09] From what I'd understand we would have to use git master as libav makes releases pretty much never - would that be a problem? [19:01:55] it might be :D we'll work it out [19:02:17] Thanks for all the info, folks [19:02:19] ok. Anyways, I'll file the ticket, and we'll see where it goes [19:03:00] For the next few weeks, we welcome your good advice on this discussion page, which is the best place for us to stay in touch, so we can improve this product together and provide a better experience for all users: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer [19:03:44] I'd like to thank everyone for joining this chat today, and look forward to more productive conversations in coming months. Please let us know what we can do to better serve our multimedia users :) [19:04:27] #endmeeting [19:04:28] Meeting ended Fri Feb 21 19:04:27 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [19:04:28] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-21-18.01.html [19:04:28] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-21-18.01.txt [19:04:28] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-21-18.01.wiki [19:04:28] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-21-18.01.log.html [19:04:40] fabriceflorin: Thank you for your always friendly words and for organizing these talks and keeping the community up-to-date. [19:04:58] fabriceflorin: Perhaps next meeting shouldn't be so close to the architecture meetings. These types of meetings tend to bleed slightly over their time slots, might be good to have a little bit of a break between them [19:05:03] Bye, bawolff, rillke, brion, dschwen, Dragonfly6-7, jfelipe and all other participants: we really appreciate your guidance and company! [19:05:56] bawolff: Good point, but nobody posted the architecture meeting on this schedule, so I didn't know it was happening: https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours [19:06:04] bye! [19:06:07] Do we know who organized that meeting? [19:06:22] it occurred totally spontaneously [19:06:27] an emergent phenomenon [19:06:28] Hope to see you soon, dschwen -- did you make it across the US OK? [19:07:14] fabriceflorin: I'm not sure. I think sumanah acts as a contact point for organizing them maybe (?) [19:07:29] Ah, thanks Dragonfly6-7 -- well I hope we didn't interrupt anything. Would it be better if we hosted these meetings in #wikimedia-multimedia rather than #office? [19:07:46] yes (apart from minor car trouble) [19:07:51] bawolff: OK, I will ping sumanah [19:08:01] still sitting surrounded by moving boxes [19:08:09] dschwen: Glad your trip went well. [19:08:10] Dragonfly6-7 is joking I think, emails for architecture meeting went out at least 5 days ago [19:08:36] dschwen : Good luck with your new gig! [19:09:31] bawolff: Thanks for the clarification. I will ask sumanah and architecture folks if they could post these meetings on the main #wikimedia-office calendar, so we don't step on each other's toes :) [19:09:38] fabriceflorin: Yeah, I told sumanah to schedule it next time [19:11:06] s/told/asked/ :) [19:11:35] Many thanks to our world class multimedia team for joining this chat: gi11es , rdwrer , tgr , pginer and Keegan -- really appreciate your contributions and hope you didn't mind if I put you on the spot :) [19:11:57] I indeed organise the RFC meetings (architecture meetings) and will be putting them on the office hours calendar in future. [19:12:16] Thanks, sumanah that would be wonderful :) [19:12:38] I thought adjacent meetings were fine; will try to allow a 15-min block between in future. [19:12:58] It was OK, it was just unexpected :) [19:13:06] sumanah: Yeah, that's usually a good idea, as conversations tend to trail in Internet time ... [19:13:39] rdwrer: Well, I didn't want to be the only one talking, it seemed better for folks to hear it from the horse's mouth. [19:14:07] I hope this kick-off chat will lead to good ongoing conversations on our discussion page ... [19:14:33] fabriceflorin: Uh, what were you replying to? [19:14:43] Oh, me talking about new features and being unprepared? [19:15:17] rdwrer: I thought you were saying that asking you to speak about what you were working on was unexpected ..... but I see now that you were responding to [19:15:34] responding to sumanah ... [19:15:41] thank you for addressing the features that I mentioned [19:15:44] Oh, yeah [19:15:56] Applicable to both I guess :) [19:16:07] Duh. This is where the lack of body language and visual cues can make these conversations harder than in the real world ... [19:16:43] Some say harder... Other's say awkward misunderstandings in language are fun and exciting! [19:16:47] It's how wars start [19:17:06] Okay, thanks everyone. I'm moving on to other tasks. See you later ... [19:17:14] bawolff: Loads of people on IRC have enough experience with awkward misunderstandings that the added noise is just flavoring [19:17:27] that's why TPP is the way it is [19:21:20] bawolff, "I think there is a god" "I do not disagree with you" "I didn't understand that. BURN THE HERETIC" [19:21:54] yep