[22:00:08] https://phabricator.wikimedia.org/E147 starting soon... [22:00:15] \o/ [22:00:22] #startmeeting RFC meeting [22:00:22] Meeting started Wed Mar 9 22:00:22 2016 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:00:22] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:00:22] The meeting name has been set to 'rfc_meeting' [22:00:36] #topic RFC meeting | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [22:01:12] so I guess we're doing notifications first [22:01:31] yup [22:01:33] hi [22:01:34] T128351 [22:01:34] T128351: RfC: Notifications in core - https://phabricator.wikimedia.org/T128351 [22:01:35] first in first out [22:01:39] +1 [22:01:54] and thumb URLs will be the end of this week plus maybe next week as well? [22:02:32] great! [22:02:56] TimStarling: yes, depending on where we end up today [22:02:57] I updated https://www.mediawiki.org/wiki/Requests_for_comment/Notifications_in_core recently with open questions and implementation plan sections [22:04:01] I thought consenus was mostly leaning to sticking most of Echo into core (with some specific open questions), but Krinkle posted something different on the bug just now [22:04:16] https://phabricator.wikimedia.org/T128351#2104701 [22:05:31] Krinkle basically suggested keeping all the DB code and UI outside core, and making it pluggable. [22:05:40] legoktm: there are five open questions there, should we step through them? [22:06:10] making it pluggable would be more work [22:06:43] Yes, my first question is whether anyone even wants to make an alterate implementation. [22:06:58] robla: my questions assumed people were in agreement that we should be moving most of the Echo backend stuff into core, but if people agree with Krinkle, those questions don't make sense [22:07:01] the main thing you need is to define a narrow interface [22:07:22] which is useful in its own right [22:07:24] It could be as sample as taking Echo's base classes, converting to an interface and adding to core. And in the process we'd also force separation between backend and logic handling (similar to what we're working on within mw for some areas) [22:07:29] so we should first figure out whether we want to have some kind of pluggable thing Krinkle proposed, or just have Echo as the core notification implementation [22:07:39] +2 to merging Echo into core (finally, if I may add) [22:07:49] the latter is a separate thing, but I think people do agree on should happen regardless. [22:08:01] and the rationale is to do a more gradual rollout to non-WMF users? [22:08:39] +1 Krinkle that was my thoughts on this [22:08:49] well if we have a plain API for it, we either need a core implementation (like Search and AuthPlugin) or to consider mediawiki as not requiring it [22:08:50] Yeah. It's been very little exposed to third parties. I think we should either halt the merge and do a bundle for a first release cycle first. Or only merge the interfaces and then bundle and stick with just that. [22:08:51] the interface is needed by skins, but they don't need to care about how it's implemented [22:09:05] what would be the behavior if an extension fires off notifications on a wiki with no notification backend? [22:09:19] a no-op default has been proposed [22:09:26] brion: >/dev/null ? [22:09:31] that sounds bad to me [22:09:36] jdlrobson, how is interface needed by skins? My understanding is people are talking about API interface. [22:09:39] brion: Yeah, just like core's RC notificaitons go no where by default. [22:09:45] jdlrobson: are you agreeing with Krinkle that echo should not be brought into core? [22:09:45] not to redis or UDP [22:09:50] I think it is useful for this discussion to separate a) interface, and b) default / alternate implementations [22:10:07] a) is fairly orthogonal to b) [22:10:07] See also my question at https://phabricator.wikimedia.org/T128351#2104841 . How do we handle places where Echo replaces core functoinality (e.g. email notif for user talk)? [22:10:10] But the interface for creating RC entries and having an RCFeedEngine are in core. [22:10:11] Krinkle: RC events aren't user-facing for most values of user, whereas this is entirely user-focused [22:10:21] brion: True. [22:10:36] TimStarling: i'm still collecting my thoughts but my immediate reaction when I saw the RFC was interfaces should be defined in core, not the entirety of the Echo system. [22:10:49] sorry, my other client is lagging [22:10:53] brion: But I don't think we're too worried about exposing Echo as an API inside HTML. So that'll work the same way either way. Point being, what do we gain by having Echo in core? [22:10:56] i can't envision many (any?) circumstances where as a core or extension author i would expect firing off a notification to a user to do nothing to be acceptable [22:11:23] we gain a consistent way for core and extension authors to provide software->user communications path [22:11:33] the consistent part comes from it always working, not just having an internal api :) [22:11:34] Echo seems like an implementation of a NotificationsEngine and I could imagine other notifications engines involving email and even the orange bar of death ;-) [22:11:51] brion: Right, so you're comparing this similar to EmailUser. It can't go nowhere by default since the application intent is to reach a user, not just to provide information in general. [22:12:00] Krinkle, main reason i think is to avoid duplicate implementations (e.g. email for user talk notif) with hooks galore, second to that is that it's an important framework, and thus arguably important enough to go into core. [22:12:01] *nod* [22:12:04] Echo has a lot of things inside of it, and I think those things are being confused. [22:12:13] matt_flaschen: Right now Echo adds itself to menus via horrible hooks and I'd prefer to see it replace some concept in core. e.g. NotificationsEngine = 'Echo' [22:12:22] jdlrobson, in theory you can make anything pluggable, but in practice does anyone actually plan to write that? It's a lot of code. [22:12:36] jdlrobson, and what happens if there is no engine and no Echo. Do you just not get email notif for user talk change? [22:12:58] Echo is a notifications framework, which includes a pluggable backend for how to deliver notifications (web, email, etc.), a system for formatting those notifications for each output type [22:13:30] matt_flaschen: defining interfaces does not necessarily imply doing the legwork to set up fancy plugging infrastructure behind those interfaces [22:13:50] duploktm: that is an excellent nickname [22:13:54] The main problem I see is that there are already notification types in core (enotifs, watchlists) which sometimes conflict with Echo, and require bad hook hacks to fight with [22:14:03] gwicke, I'm responding to Krinkle and jdlrobson (both of whom did propose making it pluggable) [22:14:05] so it sounds like echo *is* the thing that defines pluggable backend interfaces [22:14:36] brion, note Krinkle even proposed making the DB backend pluggable. Echo does not support that and there has been no prior discussion of that. [22:15:04] brion: which brings into question the idea of using echo base classes as the core notification API [22:15:09] what is the point of moving it into core, or define an interface in core? [22:15:11] I'm all for interfaces and separating business and frontend logic and whatnot, but I don't think that separation needs to be enforced by extension vs. core and physical git repos [22:15:11] matt_flaschen: You can scrap that detail. I'm not pushing for that. That could be injected to the handler instead of being known to core directly. [22:15:20] is there a clear articulation of the value somewhere? [22:15:23] echo would become a collection of backends instead of a single thing [22:15:29] Okay, fair enough. [22:15:31] ori: https://www.mediawiki.org/wiki/Requests_for_comment/Notifications_in_core#Problem [22:15:36] ori: to ensure it is always available so can be used and relied upon by core and extension authors making features for users [22:15:38] And I agree there isn't much value in anticipating a backend and handling logic from different authors at this point. [22:15:51] least that's my goal ;) [22:15:56] Note that MediaWiki doesn't ship with a default skin, you have to install a skin. I'd expect a similar kind of abstraction with Echo. [22:15:58] ori, I think main concrete benefit is that we don't have to have to versions of the same thing (e.g. user talk notification). Later on, we could also look at unifying watchlist and Echo if it makes sense. [22:16:15] The idea "important infrastructure should be in core" might also apply, but isn't concrete. [22:16:24] ori: Another thing people noted on the phab task is that Echo and notifications in general have become an integral part of using MediaWiki - at least on Wikimedia wikis where it is installed [22:17:04] Suppose we move it into core. The extensions that want to make use of the new Echo functionality in Core have to either: [22:17:29] (a) drop the old code that works with the Echo extension, and express a dependency on the version of MediaWiki that introduced this work [22:17:57] (b) keep the old code, and add _additional_ class_exists & co checks [22:18:03] a) is how we usually roll [22:18:10] jdlrobson, again, why? At the time the decision was made to stop shipping skins, there were already many skins (in core and elsewhere). There is only one notification framework I know of. [22:18:16] so why not just express a dependency on Echo? [22:18:29] yup (a) [22:18:43] ori: sorry, but did you read the RfC? I proposed keeping a back-compat shim with old class names so neither a nor b would be necessary [22:19:11] ori: because of the reasons on the wiki page that duploktm just linked to [22:19:47] you mentioned "a back-compat layer for things that haven't transitioned to core notifs yet " as something that would stay in Echo [22:19:54] not that there would be a shim in core [22:20:02] ori, he's talking about a shim in Echo [22:20:03] "Being in an extension, Echo has to use ugly hooks to suppress some core features" [22:20:15] So if you're already depending on Echo, just keep doing it until you feel like changing your extension to drop the Echo dependency. [22:20:17] (in wmf-maintained extensions folks love to remove old interfaces and clean them up. in third-party-maintained extensions folks tend to run back-compat. one of my concerns is making sure third-party extension authors have one fewer compat choice to make in the future) [22:20:18] Talkpage notifications are a good use case to figure where the boundary is. It's the kind of notification we expect to be delivered (non-optional) and is in core currently but aborted by Echo to use its own instead (still sent as e-mail but formatted by echo instead of core) [22:20:20] which implies that core should depend on Echo, not just other extensions [22:20:54] ori: if it already has notifications, it already depends upon Echo...? [22:20:57] *nod* core sends notifications too, not just other extensions [22:21:16] +1 to Krinkle and brion. This is the main concrete benefit I see. [22:21:34] if i understand correctly ,the idea is to have all the actual code in core, and just a shim in the extension, for compat [22:21:45] I think notifications could have an indication (if not already) whether delivery is important. People don't use the wiki always. So I disagree Echo is a meant of direct delivery. I"m sure many people never look at it. [22:21:45] that way, core wouldn't depend on the extension [22:21:52] now we _could_ have an abstract interface with a simple concrete implementation. i just feel like the echo code maybe is a better way to do that than inventing a new default implementation [22:21:57] And if so, then the default implementation in core is to send an e-mail like it does now [22:22:07] It would allow Echo to replace it much more cleanly [22:22:08] DanielK_WMDE_: yes, I was just in ori's universe for a minute [22:22:17] heh [22:22:22] Krinkle, how, though? Would core have a simple $wgNotificationHandler? [22:22:23] I think merging all of Echo is overestimated. It's not going to solve as many problems as we might think. [22:22:28] Note Echo also has email notifications. [22:22:33] And they can be enabled by default. [22:22:36] matt_flaschen: Yes, and it effectively does already [22:22:55] Krinkle, yes, not in a deliberately pluggable way. But yeah, it's a proposal to consider. [22:22:57] matt_flaschen: Exactly. It replaces that functionality with a nicer preference and pretty e-mail. [22:23:08] email is presumably not going to provide as many features as echo [22:23:12] Krinkle: So you're proposing only the email part of Echo be merged into core, and the web notification stuff be kept in the extension? [22:23:18] for example merging of duplicate messages [22:23:55] Yeah there are some features unique to rendering notifications on the web [22:24:12] Non-important notifications that are web-only by default would go nowhere without Echo installed. [22:24:14] so if email is the default backend and an API user is expecting message merging then you will end up making non-optimal design choices [22:24:17] matt_flaschen: maybe the confusion is around the use of the word "echo". I am advocating for a notifications engine in core, but not the entirety of the Echo extension. So far Krinkle is not saying anything I disagree with.. :) [22:24:20] Such as what TimStarling said ("merging of duplicate messages", which we call "bundling"), and also i18n-y things like dealing with different languages and bidi embedding etc [22:24:31] yeah that [22:24:32] FWIW, i think it would be very good for core to have the notion (that is, an interface) of a notification service that can be used to send notifications to users. The interface can, for now, be implemented directly by echo, no need for a fancy registry mechanism just yet. Would be nice if we could fit email notifications in there too, though. [22:24:37] apologies if my terminology is confusing [22:24:38] jdlrobson: what does "notifications engine" mean? [22:25:09] DanielK_WMDE_: +1 [22:25:54] DanielK_WMDE_, how can we handle existing core functoinality like core talk page email notifications without a registry system or unconditionally replacing that functionality with Echo? [22:26:13] Is anyone proposing an alternative implementation of a "notifications engine" or are we just hearing that code in core really shouldn't be shitty? [22:26:16] When installed, Echo would take over all e-mail notifications. That seems reasonable. [22:26:17] Krinkle has proposed (IIUC) a registry system with a simple implementation in core, and then Echo replacing that core implementation. [22:26:25] matt_flaschen: fittign in email notification would have to wait until we do have some kind of registrytion mechansim [22:26:28] the expected value of this work doesn't seem commensurate with the effort involved [22:26:36] DanielK_WMDE_ then to me we're not getting any benefit to the RFC. [22:26:49] but if legoktm can / wants to do it without breaking things in the process then so be it [22:26:55] matt_flaschen: If you call "refactor existing core code" a simple implementation, then es. [22:26:56] yes* [22:26:58] matt_flaschen: not getting benefit from what? [22:27:13] "simple" relative to echo [22:27:18] Krinkle: maintaining duplicate implementations of similar functionality, except one of which is never used on the Wikimedia cluster is one of the things I'd like to move away from [22:27:18] ori: are you referring to the 'split everything into interfaces and implementations more than it already is' or the 'merge to core' scenarios? [22:27:26] DanielK_WMDE_ if we have a core notification service but the existing email notifs (already in core) don't play by the rules of that service, what's the point? [22:27:28] duploktm: No duplicate functionality. [22:27:43] Krinkle, simple compared to effort, not simple refactoring work. [22:27:48] simple compared to Echo [22:27:50] Sorry [22:28:03] Krinkle: so core would have no email notifs then? What is Echo taking over? [22:28:14] brion: Both. These sorts of projects don't tend to go well unless they are tied to a feature goal [22:28:22] matt_flaschen: my idea is to fit in Echo, using an interface that can later also be used by ENotif. Once that is done, we can refactor thigns and add a registry, and hook in ENotif too. The interface should be designed with that in mind [22:28:44] ori: feature goal is to ensure that server->user notifications are consistently available as a service to other features in both core and extensions. [22:28:53] I believe the main point of contention is how core talks to the notification engine or whatever. What does that interface look like? [22:29:00] duploktm: The interface for creating notifications would move, not be duplicated. [22:29:00] duploktm my definition would be something that allows registering notifications for users and is either agnostic to how they are delivered or uses email to deliver them by default [22:29:06] ori: this is mostly a tech-debt cleanup RfC [22:29:10] duploktm: And used by core instead of what it does now for email notifications. [22:29:20] DanielK_WMDE_, also in contention whether to move UI to core. [22:29:29] Krinkle: so we'd still end up with two implementations of email notifs right? [22:29:34] ori: so while other extensions can declare dependency on echo without that merge, features in core cannot do that reliably today [22:29:36] ori: you do have a point on that - but its my understanding the collaboration team have goals around Echo no (judging on latest cross wiki notifications) so I'd hope it would be tied to those? [22:29:52] If you want a feature goal around this, consistent emails is one [22:29:55] jdlrobson: ...that's what Echo currently is. [22:29:58] enotif emails and Echo emails look different right now [22:30:02] duploktm: There will likely be a class to be extended by core, but I doubt it would actually duplicate anything. [22:30:06] matt_flaschen: ...and the storage backend. but my impression was that that wasn't so controversial. [22:30:31] it's not like our feature-driven projects have a stellar track record [22:30:50] DanielK_WMDE_, I think Krinkle withdrew the idea of making that separately pluggable, so he's now suggesting just one pluggable (notification system) with an implementation in core that Echo would replace if enabled. [22:31:32] I agree that the benefits should clearly outweigh the costs, but don't think that features are the only way to get focus and good cost / benefit ratios [22:31:33] brion: yeah, I think it's valid, just not commensurate with the risks [22:31:48] ori: fair enough, I just come down on other side of that :) [22:31:56] matt_flaschen: sounds good, except that i would be fine with echo being that implementation in core. Rewriting it doesn't sound too appealing. [22:32:17] Yes, it's still open whether that's worth doing. [22:32:21] Maybe an alterate proposal would be: [22:32:39] 1. Bundle Echo in tarball for a release, as I think Krinkle suggested. [22:33:04] 2. Merge Echo (either in entirety, or just the logic part) into core. [22:33:08] duploktm: well there's a lot of frontend code too that doesn't seem to fit into that definition. I don't think formatters fit into that definition. [22:33:23] The web UI part could potentially stay separate even if there was no other notification system in core, but that still adds complexity. [22:33:26] matt_flaschen: we could also have a dummy implementation be the default. [22:33:48] (2) seems like a good idea. It would be very ugly at first, but then the things about Echo that are extension-y could be replaced gradually [22:33:58] so there isn't a big, risky mega-commit [22:34:14] Yes, I'd like to do this gradually, not one giant thing [22:34:38] The main things we advertise as gains are the lack of good extension points in core and duplicated code right now between core and echo [22:34:39] There's a lot of small areas that can be worked on like moving the "Notifications" preferences tab into core for example [22:34:43] Yeah, the RFC actually suggests to do it in entirety, but piece by piece. [22:34:46] We can (and will either way) fix that. [22:35:01] But I don't think there's any positive value gained out of merging Echo itself into core. [22:35:20] Krinkle, not having to maintain another notification implementation (the simpler email system). [22:35:30] When you say "Echo itself", what do you mean? [22:35:32] i find the 'itself' to be the sticking point [22:35:34] Evidently there are some things you think should move in core and some things you think shouldn't [22:35:37] jdlrobson: if it has to send emails, it needs to be able to format. And through experience, the formatting and backend code is tied together, you can't change one without changing the other [22:35:53] matt_flaschen: That's not true. It wouldn't be a separate system. [22:36:28] Krinkle, I'm talking about the existing enotifs. Aren't you proposing core would provide a wgNotificationHandler to do that, and Echo would have its own if enabled? [22:36:48] Quick question: How many people have actually read through the current Echo interfaces and how they are used to create and format notifications? [22:36:51] matt_flaschen: Yeah, but why would Echo have to duplicate the core one? Extensions can extend. [22:36:58] Also, let me point out that emails also means email digests. The logic around that is "fun" [22:37:08] I think this might be easier if I outline what the interfaces would look like in core. [22:37:20] ++ outline [22:37:29] I know the existing interfaces but +1 for an outline [22:37:36] The RfC focuses mainly on the icky parts of Echo, not the actual good things it does [22:37:39] Because I always like concrete proposals better [22:37:48] Okay, that's fair. It wouldn't have to be a totally separate implementation but it's still a valid question if we need "base email" and "Echo email". [22:38:19] so I guess discussion of this will continue on phabricator [22:38:25] matt_flaschen: The Email notification class woudl likely be extended by Echo and overload a method or two. [22:38:25] duploktm: +1 for defining those interfaces [22:39:08] could the main people expressing opinions here write up a position statement as a phabricator comment? [22:39:35] i believe that's TimStarling-speak for "tactfully, sirs, we are out of time for this subject and must move on" [22:39:52] brion, RoanKattouw, matt_flaschen [22:40:02] * brion goes to phab [22:40:03] Yep, will do [22:40:07] Krinkle has already written some stuff so can probably reply to the things other people write [22:40:27] yeah I'm aiming for topic switch between 40 and 45 past [22:40:28] good move to directly summarize on phabricator [22:41:21] are there any action items for duploktm, e.g. expanding the RFC document? [22:41:40] I guess most people didn't read it so maybe it's a waste of time ;) [22:42:29] #action legoktm to outline/define what the core interfaces would look like, and more specificity on what the different parts of Echo actually do [22:43:47] #topic Content hash based thumb URLs | RFC meeting | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) [22:43:55] #link https://phabricator.wikimedia.org/T66214 [22:44:23] I think gwicke has some urgent questions that need to be addressed, then we will probably have a followup meeting next week [22:44:36] sounds about right :) [22:44:45] okay, let me give some background on this one [22:45:14] this task started out discussing content hashes instead of names, but morphed into a general discussion about a thumb API [22:45:46] https://phabricator.wikimedia.org/T66214#2087098 describes how those two relate [22:46:46] (are you done gwicke?) [22:46:47] the central problem of the api portion is letting clients select the size and possibly quality of thumb images, so that we can stop wasting time, cpu cycles and documentation complexity on API end points that return different-sized thumb references [22:46:49] the one downside of treating the opaque-id (has etc) and the stable-predictable-URL-based-thumbnailing-API questions separately is that it raises back the question of cache stability fo rthe URLs [22:47:06] can I make a comment on process for this? [22:47:29] paravoid: permission granted [22:47:35] I'll preface this with a statement that I'm not particularly opposed to this idea [22:47:44] and it does make sense to me to some extent [22:47:57] but, it seems that we have two issues conflated into one RfC, which has created some confusion [22:48:29] and moreover, I think it's essential when designing an API to talk about its envisioned use cases, and I don't see much there [22:48:31] paravoid: I agree, and I did consider actually splitting the task [22:48:33] on that task, I mean [22:48:56] I see e.g. Android and iOS apps tags on the task, but not actually a description of their needs [22:49:17] and finally, it's still completely unclear how/where this would be implemented (and by whom) [22:49:49] that's all [22:50:31] yeah, a summary of use cases would be nice; there is a lot of detail in the discussion, but no short summary of the most important points [22:50:47] nod [22:50:47] Paravoid: thanks [22:50:55] good notes :) on the apps, main thing they need is to be able to take a given image and fetch it at a given size reliably, with a minimum number of network round-trips [22:51:15] how is that not currently possible? [22:51:17] it's hard to rely on the raw thumbnail URLs currently as asking for too large an image may fail etc, or you may have a funny format that's ahrd to predict [22:51:22] yeah, I've heard this before but it's not very clear from the task -- and I'm not sure what /else/ would they need for example [22:51:29] eg you hvae to know to map .svg to .svg.png [22:51:32] how does purging work for different sized thumbnails? [22:51:39] we are discussing the right size to serve on tasks like https://phabricator.wikimedia.org/T125983, but ultimately none will work for every consumer [22:51:46] is the current mechanism sufficient? [22:52:13] I am not even sure whether old images can contain slashes in their name [22:52:16] brion: yea, ran into that back in the toolserver days :) [22:52:18] there are also secondary concerns like wanting to be able to ask for sizes differently (mobile web/apps frequently want cropped-to-square thumbnails which is different from the max-bounding-box) [22:52:30] where just having a clean way to extend the URL-based api would be nice [22:52:30] as an example: I had previously heard a need for thumbnails that would crop/center on faces [22:52:42] client-side quality selection based on bandwidth, device specs etc is a common need [22:52:48] pretty sure image names can't contain slashes [22:53:05] yeah image names cannot contain slashes :) [22:53:21] yes, because the whole image path is suppose to correspond to the actual file path on basic mediawiki instances [22:53:22] let's make sure we capture these notes on the task! [22:53:22] definitely not new ones, I'm less sure about historical ones [22:54:06] the filerepo code seems to support slashes [22:54:51] filerepo needs to be able to handle relative paths in some places, but identifiers for files *should* not allow /s. if they do.... that may be a bug ;) [22:54:57] in any case, rewriting thumb URLs is not something that was designed as a sane API, and is probably not something we should promote to one [22:55:00] slashes in filenames sounds like actively looking for trouble [22:55:27] https://www.mediawiki.org/wiki/Manual:Configuring_file_uploads#Known_problems_with_database_names_having_non-alphanumeric_characters :) [22:55:42] ok we're running short on time, anything else to add? [22:56:10] so the task proposes a simple strawman, and I'd like some input on that [22:56:43] if it's going to include all the needs we've just mentioned (destination format, cropping) it's looking more and more like the IIIF feature set [22:56:53] maybe a bit more than that, but it's a format we can participate in [22:56:59] a prototype of this would be fairly easy to implement; a production version should not duplicate cache entries, so the translation between old & new style URLs should ideally happen in Varnish [22:57:21] thumbor also has its own url format that covers most, if not all of that. but that's not a standard. can be used as inspiration, though [22:57:55] yeah IIIF is something i'm looking into actually as well :) [22:58:00] brion realized that most of those advanced features are normally server-supplied [22:58:01] so i'll read up on that and add more notes [22:58:12] doing the translation in varnish is how you're going to give ops nightmares. what's the VCL going to look like when it's version 6, 7 of the API and all the old URLs still have to redirect? [22:58:22] great meeting and developing process, all! thank you :) [22:58:33] paravoid: images cropped around the focal point of the image is a use case for "hero images" such as the native apps and hovercards use. In the apps they do it client side using native libs but on the web we need a backend (thumbor) to do it. [22:58:35] two things that weren't clear in the task [22:58:46] is this going to happen in MediaWiki core? [22:58:48] tgr: maybe next week or on the task? [22:58:50] nod, I'm not very fond of adding this kind of complexity at the edge [22:58:55] it's 58 past now [22:59:00] ok [22:59:20] paravoid: it's the only way to use edge-cached content, afaik [22:59:21] depends on the amount of the complexity of course [22:59:27] we'll presumably have a second meeting on this next week [22:59:41] sort of -- you could go through a transition with the old URLs redirecting in theory [22:59:41] next week: https://phabricator.wikimedia.org/E66/26 [23:00:05] that's something that we'll need to do at some point if we decide to do content hashing URLs, right? [23:00:21] yes, there will need to be a translation service & redirects [23:00:25] don't design this API with only existing use cases in mind and assume it's rarely going to get updated. that's exactly how we got our ugly thumbnail urls [23:00:40] I hope noone suggests that we do old URL -> content hash URL mappings in varnish :) [23:00:42] gilles: thumb urls weren't even designed as an api [23:00:51] gwicke: translation service? [23:00:53] they were just a way to somehow internally reference images [23:01:08] ok to end the meeting now? [23:01:10] not even that afaik -- they were just the directory structure on the web server that served them [23:01:15] in any case, I would appreciate your input on the task [23:01:27] will do [23:01:31] what you propose isn't an API, it's a URL format. let's call it what it is. semantically a REST API for images should support PUTs, DELETEs, etc. [23:01:49] if it's only GETs it's another URL scheme that's all [23:02:19] #endmeeting [23:02:20] Meeting ended Wed Mar 9 23:02:19 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:02:20] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-09-22.00.html [23:02:20] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-09-22.00.txt [23:02:20] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-09-22.00.wiki [23:02:20] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-09-22.00.log.html