Agenda
- Location: #wikimedia-office IRC channel
- Topic: T128351: Notifications should be in core
- Meeting type: Field narrowing
Meeting summary
- Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (robla, 21:02:34)
- LINK: https://phabricator.wikimedia.org/T128351 (robla, 21:03:07)
- LINK: https://phabricator.wikimedia.org/T128351#2500149 (matt_flaschen, 21:08:01)
- first part of the conversation was about whether it makes sense to add Echo to core, and make MediaWiki more monolithic (robla, 21:14:53)
- discussion about the separation of detection, routing, and delivery as three portions of a notification framework (robla, 21:25:18)
- 14:27:23Â <matt_flaschen>Â On the other hand, TimStarling said mention is "really essential for everyone" if I understand correctly. So why not put some of that in core, playing devil's advocate (it's not a big deal either way really)? (robla, 21:28:27)
- 14:32:02Â DanielK_WMDE: then the question is just, which of the event types in Echo should be in core, and which don't need to be. RoanKattouw: Yes, exactly.[...] (robla, 21:33:33)
- 14:33:53Â <RoanKattouw>Â robla: Uhm.... that's not what I said (robla, 21:34:12)
- That's only one of the questions. There's also what parts of Echo framework and UI to move to core. (matt_flaschen, 21:34:28)
- 14:39:58Â <DanielK_WMDE__>Â TimStarling: can you define the sides <TimStarling>Â essentially small coreecho versus large coreecho (robla, 21:41:48)
- 14:40:57Â <TimStarling>Â the large coreecho side would put presentation, detection, etc. in core (robla, 21:42:23)
- 14:41:52Â <TimStarling>Â the small coreecho side would have an interface and basic or null implementation in core (robla, 21:42:57)
- <tgr> I think everyone agrees on figuring out a workable general interface and having everything use it (DanielK_WMDE__, 21:45:56)
- <DanielK_WMDE> can you say what those interfaces would be? <tgr> a service to queue objects which implement some EchoEvent interface (and support serialization), a service to map event objects to callbacks which route events to users, and something about presentation although I expect things will break down there (DanielK_WMDE, 21:51:28)
- <matt_flaschen> tgr, it's important to distinguish user location (which I think people here are calling routing) and delivery. (DanielK_WMDE__, 21:52:26)
- ACTION: robla define next steps in the RFC (robla, 21:57:12)
Meeting ended at 22:00:49 UTC.
People present (lines said)
- matt_flaschen (53)
- RoanKattouw (41)
- DanielK_WMDE__ (40)
- TimStarling (35)
- robla (31)
- tgr (20)
- mooeypoo (19)
- bd808 (10)
- SMalyshev (6)
- wm-labs-meetbot` (3)
- Scott_WUaS (2)
- stashbot (1)
- quiddity (1)
Full log
| 1 | 21:02:17 <robla> #startmeeting ArchCom RFC Meeting W31: Notifications in core E251 |
|---|---|
| 2 | 21:02:17 <wm-labs-meetbot`> Meeting started Wed Aug 3 21:02:17 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 3 | 21:02:17 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 4 | 21:02:17 <wm-labs-meetbot`> The meeting name has been set to 'archcom_rfc_meeting_w31__notifications_in_core_e251' |
| 5 | 21:02:34 <robla> #topic Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ |
| 6 | 21:03:07 <robla> #link https://phabricator.wikimedia.org/T128351 |
| 7 | 21:04:01 <robla> T128351 is the main topic today. Last week, when ArchCom discussed this, we thought it might be ripe for a decision |
| 8 | 21:04:02 <stashbot> T128351: RfC: Notifications in core - https://phabricator.wikimedia.org/T128351 |
| 9 | 21:04:36 <robla> brion documented the choice that he was hoping we'd be able to settle on this week |
| 10 | 21:05:10 <robla> I think we can declare this discussion a field narrowing discussion where we clarify what options we have |
| 11 | 21:07:03 <robla> so: how much of Echo should we move into core: a) very little, coming up with a minimal interface or b) pretty much all of it? |
| 12 | 21:07:08 <robla> thoughts? |
| 13 | 21:07:41 <bd808> The talk of inventing a new interface seems strange to me. |
| 14 | 21:07:45 <matt_flaschen> robla, brion documented meaning "We still have to discuss the 'line' of how much of Echo infrastructure needs to be moved to core"? |
| 15 | 21:07:49 <Scott_WUaS> HI! |
| 16 | 21:08:01 <matt_flaschen> https://phabricator.wikimedia.org/T128351#2500149 |
| 17 | 21:08:52 <matt_flaschen> Agree with bd808. I favor merging it all into core in a clean (possibly multi-step) way (of course not "move the extension into a directory in core and hook it up like an extension"). |
| 18 | 21:08:58 <robla> matt_flaschen: yup, that's the documentation I was referring to |
| 19 | 21:09:02 <DanielK_WMDE__> bd808: you want to keep using hooks? |
| 20 | 21:09:20 <matt_flaschen> But, other people on Collaboration team such as mooeypoo have different views. |
| 21 | 21:09:31 <bd808> DanielK_WMDE__: no, there would be no need for hooks into core if integrated |
| 22 | 21:09:41 <mooeypoo> I think it's worth asking the question what do "base" 3rd party MediaWiki users expect/need vs. what Echo gives right now. Personally, when I thought about this question, I reached the conclusion that I think Echo is too robust for general use - we have cross-wiki notifications, for example, that many basic uses of MW don't require (and the implementation is more than "just" a few bits; we have widget logic, back-end logic, and designs fo |
| 23 | 21:09:41 <mooeypoo> r it) and there are a few more of these. |
| 24 | 21:09:48 <bd808> but maybe that was where I got confused |
| 25 | 21:10:41 <matt_flaschen> mooeypoo, yeah, but it's fully functional without that. And there is already supporting code for cross-wiki in core that many installs don't use (e.g. CentralIdLookup). And no doubt other things in core would be simpler if CentralAuth didn't exist. |
| 26 | 21:10:46 <tgr> so the concern is that Echo is hard to install / administer for third parties? |
| 27 | 21:10:59 <mooeypoo> I personally think we should stick to a workable interface in core that allows users to product/view notifications, and leave the more robust and/or specialized implementation in Echo as an "added" behavior. That would let people decide whether they want or need to use it, while still getting basic functionality, if that makes sense. |
| 28 | 21:11:01 <tgr> a supposed MW core into which Echo has fully been merged, I mean |
| 29 | 21:11:02 <matt_flaschen> tgr, it's extremely easy to install in my opinion. |
| 30 | 21:11:04 <DanielK_WMDE__> bd808: well, the core code needs to call some method to say "this event just happened, notify whoever is interested". that's the "new interface" |
| 31 | 21:11:09 <RoanKattouw> I don't think Echo is hard to install at all |
| 32 | 21:11:21 <DanielK_WMDE__> bd808: i just want to know what that method would look like |
| 33 | 21:11:22 <mooeypoo> matt_flaschen, yes, I think ideally those shouldn't be there either, but that's a different issue :P |
| 34 | 21:11:35 <bd808> vagrant role enable echo; vagrant provision -- ;) |
| 35 | 21:11:35 <matt_flaschen> The only real benefit I see to merging into core is to fully unify all notifications. |
| 36 | 21:11:35 <tgr> I don't really see the disadvantage of shipping core functionality that most people won't need |
| 37 | 21:11:50 <tgr> we have WikiMap in core and whatnot |
| 38 | 21:11:50 <matt_flaschen> No more watchlist emails/password reset emails/whatever that look weirdly different from other notifiations (Echo). |
| 39 | 21:12:02 <matt_flaschen> All notifications should act and look the same. |
| 40 | 21:12:08 <DanielK_WMDE__> tgr: depends on how much it adds to the monolith... |
| 41 | 21:12:10 <RoanKattouw> There are issues with /fully/ integrating enotif and Echo |
| 42 | 21:12:22 <matt_flaschen> We don't often have to deal with annoying core/Echo cross-repo coordination, so I don't find that convincing. |
| 43 | 21:12:26 <matt_flaschen> Sometimes, yeah, but not often. |
| 44 | 21:12:27 <RoanKattouw> But I agree that email consistency would probably be easier to achieve |
| 45 | 21:13:05 <mooeypoo> tgr, I agree with that. I also think we should consider MW core as "tight" core as possible (i think you mentioned symphony and components... we might not be working at that "level" of separation, but I think it is not a bad idea to still keep that kind of thing in mind) |
| 46 | 21:13:24 <matt_flaschen> RoanKattouw, there are two possible levels of "look the same", actually being Echo notifications and using part of the rendering stack. |
| 47 | 21:13:35 <RoanKattouw> Yes, that's largely what I was getting a |
| 48 | 21:13:36 <RoanKattouw> t |
| 49 | 21:13:50 <RoanKattouw> I think there'd be problems making them actual Echo notifs, but they could use the same rendering stack |
| 50 | 21:13:56 <tgr> I think making MW core less monolitic would be great, but extensions are not necessarily the right tool for that |
| 51 | 21:13:57 <matt_flaschen> But things like $wgEnotifUserTalk could be fully unified. |
| 52 | 21:14:08 <matt_flaschen> (Instead of replaced by an extension) |
| 53 | 21:14:12 <RoanKattouw> Another advantage of having notification support in core in some form is that random other extensions such as EducationProgram or ContentTranslation wouldn't have to depend on Echo |
| 54 | 21:14:13 <mooeypoo> RoanKattouw, matt_flaschen I think that in the consideration of whether to bring Echo into core we should separate the two issues -- "should we" and "will it make things easier to code". Those are two different aspects that require different strategies. If we decide it's bad, we can solve for the "will it be easy to code" separately, for example... if that makes sense. |
| 55 | 21:14:27 <TimStarling> mooeypoo: conceptually, extensions are optional, if you have a required extension then it is a library, not an extension |
| 56 | 21:14:51 <mooeypoo> TimStarling, yes. Which is why I think MW core **should** have that functionality. I am just not convinced it should include all of Echo's functionality. |
| 57 | 21:14:53 <robla> #info first part of the conversation was about whether it makes sense to add Echo to core, and make MediaWiki more monolithic |
| 58 | 21:15:37 <matt_flaschen> "random other extensions such as EducationProgram or ContentTranslation wouldn't have to depend on Echo" |
| 59 | 21:15:40 <matt_flaschen> What's wrong with them doing so? |
| 60 | 21:15:49 <matt_flaschen> Also, it can be a soft dependency already. |
| 61 | 21:15:53 <RoanKattouw> Yes, that's true |
| 62 | 21:16:06 <RoanKattouw> It's more convenient if there's a core API, is what I meant |
| 63 | 21:16:35 <bd808> Extensions depending on each other can get pretty sticky |
| 64 | 21:16:44 <robla> is notifying other users about activity at the heart of what MediaWiki's job is? |
| 65 | 21:16:48 <bd808> lots of ways that it becomes difficult to setup or upgrade things |
| 66 | 21:17:06 <mooeypoo> robla, isn't it already doing that with watchlists? It seems to me that Echo expands on that concepts, not really invents it. |
| 67 | 21:17:12 <DanielK_WMDE__> it seems to me that we are really talking about three kinds of functionlity. perhaps it makes sens to discuss them separately. 1) detecting evens (user mentioned, etc), 2) routing notifications (who is interested in image X being used), 3) delivering notifications (popup, email, orange bar...) |
| 68 | 21:17:16 <matt_flaschen> robla, I think it's pretty essential functionality, though not necessarily Echo-style notifications, as RoanKattouw said. |
| 69 | 21:17:24 <mooeypoo> ^ agreed with matt_flaschen |
| 70 | 21:17:24 <bd808> robla: For me personally, I think change notification is pretty core to collaboration |
| 71 | 21:17:26 <matt_flaschen> But even core has at least one Echo-style notification (user talk notifications). |
| 72 | 21:17:56 <matt_flaschen> And maybe would have more if there were a better notification framework in core. |
| 73 | 21:18:32 <tgr> yes, notifications are at the heart of any social software |
| 74 | 21:18:37 <TimStarling> it probably would have more |
| 75 | 21:18:46 <DanielK_WMDE__> I think wwe should have implementations of delivery in core, but perhaps only very basic routing and detection. |
| 76 | 21:18:47 <matt_flaschen> mooeypoo, do you want to describe your thoughts on the line of what should be in core? |
| 77 | 21:19:15 <tgr> and the current UX is very fractured (Echo, core mails, orange bar of doom in different varieties) |
| 78 | 21:19:21 <TimStarling> we should have notification for (non-user) talk page replies in core |
| 79 | 21:19:27 <mooeypoo> matt_flaschen, I personally think that one of the greatest things about our projects (true for other FOSS i guess) is that we sometimes get surprises on what people do to utilize stuff that we give them -- that's my main point about giving a certain framework+API for notifications in core, and then leaving the **specific** implementation of which notifications,how,which are bundled, etc in Echo. |
| 80 | 21:19:43 <tgr> if you want a unified UX, I don't see how that would happen without making the presentation part of Echo part of core |
| 81 | 21:19:49 <TimStarling> echo at least has a notification when someone mentions your name, which is really essential for everyone |
| 82 | 21:19:56 <DanielK_WMDE__> tgr: +1 |
| 83 | 21:19:58 <matt_flaschen> tgr, orange bar of doom is replaced by Echo. The fact that it looks vaguely similar is for product reasons, not an accident (users wanted it like that) |
| 84 | 21:20:18 <RoanKattouw> DanielK_WMDE__: I disagree. I think we should have a good notification routing platform in core, perhaps some detection/production although some of that can be in extensions too, and at least some delivery/rendering although some of that can be in extensions too. But the middle part of that (taking the notification from the code that produced it to the code |
| 85 | 21:20:18 <RoanKattouw> that renders it) should be in core IMO |
| 86 | 21:21:03 <mooeypoo> tgr, I'd separate the presentation part from the implementation of the notification framework, though. we could definitely have base presentation in core while still having it be "simpler" to allow people to either use what we do in Echo or do something different. |
| 87 | 21:21:06 <RoanKattouw> I have no strong opinions on whether presentation/rendering of notifs is moved fully from Echo to core or not. But I think the main value is in having the backend notifications infrastructure in core |
| 88 | 21:21:14 <DanielK_WMDE__> RoanKattouw: that actually sounds like we agree... where do you think we do not? |
| 89 | 21:21:31 <matt_flaschen> mooeypoo, I'm concerned that we tend to change API pretty tightly in coordination with UI. |
| 90 | 21:21:38 <matt_flaschen> How will that work if the API is in core, but the fancy UI is in Echo. |
| 91 | 21:21:57 <mooeypoo> We make a lot of decisions about how we think notifications should look like and behave in Echo -- those are decisions that work for the majority of our users (def in production Wikipedia & sister projects) but 3rd parties may decide they want to create different ways to consume those notifications, and I think that's something we should allow. |
| 92 | 21:22:19 <tgr> mooeypoo: I agree people should be able to replace (parts of) the notification framework, but having the implementation in core does not prevent that |
| 93 | 21:22:40 <tgr> you can do it for emails, for example, even though the mail sending code is part of core |
| 94 | 21:22:57 <mooeypoo> tgr, I guess not. I just conceptually prefer having the "base" in core and extending it outside (component-like) rather than the implementation in core and having people override/rewrite it |
| 95 | 21:23:06 <tgr> and MediaWikiServices is good groundwork for making it possible in a non-horrible way |
| 96 | 21:23:17 <mooeypoo> but that's a personal preference, I guess? I see it more conceptually sound, but I'm not sure if I can fully explain why, except for "because that's how I like it" ;) |
| 97 | 21:23:29 <matt_flaschen> tgr, yeah, good point. One option is to move everything into core, but still make as much as possible pluggable. |
| 98 | 21:23:35 <matt_flaschen> (Replaceable by third-party components). |
| 99 | 21:23:36 <DanielK_WMDE__> tgr, RoanKattouw: i agree that the infrastructure for all three (detection, routing, delivery) should be in core. i'm not sure all detection and routing logic currently in echo should be in core. the delivery/presentation stuff should very likely be in core, though. |
| 100 | 21:23:53 <RoanKattouw> What part of the routing logic do you think does not belong in core? |
| 101 | 21:23:54 <matt_flaschen> Though I'm a little worried if anyone will actually bother to write a serious third-party component for any of the pluggable parts. |
| 102 | 21:24:02 <tgr> I agree with TimStarling that libraries are a better concept for separating stuff and making it easy to replace |
| 103 | 21:24:09 <bd808> they won't |
| 104 | 21:24:37 <DanielK_WMDE__> matt_flaschen: we would, so we don't have to ship all logic we want in production to ship with the bare bone version of core. |
| 105 | 21:24:37 <bd808> I could see an extension that did mobile push |
| 106 | 21:24:48 <matt_flaschen> DanielK_WMDE__, one option is to move the entire framework, plus UI (popup, special page) into core, but have actual notifications (e.g. mention, page links) stay in extensions. |
| 107 | 21:25:01 <matt_flaschen> DanielK_WMDE__, is that what you mean by "detection"? |
| 108 | 21:25:02 <TimStarling> supposing we merge most or all of echo into core, producing "coreecho" |
| 109 | 21:25:14 <DanielK_WMDE__> matt_flaschen: yes, that's what i'm thinking should be done. |
| 110 | 21:25:18 <robla> #info discussion about the separation of detection, routing, and delivery as three portions of a notification framework |
| 111 | 21:25:19 <TimStarling> then coreecho can be the hookable thing, modified by extensions |
| 112 | 21:25:22 <tgr> bd808: mobile push, SMS, Slack integration... I don't think it that unlikely at all |
| 113 | 21:25:35 <bd808> yeah |
| 114 | 21:25:37 <TimStarling> extensions then have a richer framework to work on top of |
| 115 | 21:25:59 <matt_flaschen> tgr, there's a difference between adding an alternative delivery and replacing an existing component. |
| 116 | 21:26:45 <DanielK_WMDE__> TimStarling: yea... coreecho doesn't have to parse for users being mentioned, or detect who uploaded an image for routing. that kind of thing can be added by an extension. |
| 117 | 21:26:58 <tgr> fair point. There seems to be very little reason to replace the existing functionality of Echo |
| 118 | 21:27:21 <mooeypoo> Conceptually speaking, though, putting Echo in core and letting extensions extend it, would mean we have a full-blown-implementation that is then being overrided by extensions, rather than having a base that extensions can use -- Echo being one of those implementations. I mean, clearly it's technically feasible, I'm just arguing that it makes less sense conceptually, and may introduce other issues in the long run for us to support other u |
| 119 | 21:27:21 <mooeypoo> ses of the system. |
| 120 | 21:27:23 <matt_flaschen> On the other hand, TimStarling said mention is "really essential for everyone" if I understand correctly. So why not put some of that in core, playing devil's advocate (it's not a big deal either way really)? |
| 121 | 21:27:34 <TimStarling> DanielK_WMDE__: I think those two things specifically could be part of core |
| 122 | 21:28:16 <TimStarling> I am basically favouring a larger version of coreecho |
| 123 | 21:28:27 <robla> #info 14:27:23 <matt_flaschen> On the other hand, TimStarling said mention is "really essential for everyone" if I understand correctly. So why not put some of that in core, playing devil's advocate (it's not a big deal either way really)? |
| 124 | 21:28:29 <TimStarling> not the interface-centric versions of this proposal |
| 125 | 21:28:36 <RoanKattouw> DanielK_WMDE__: OK so by "detection" you mean notice that something happened, and by "routing" you mean figure out who should be notified |
| 126 | 21:28:42 <RoanKattouw> I see |
| 127 | 21:28:56 <DanielK_WMDE__> TimStarling: if we do them nicely/cleanely, yes. as long as detecting mentions is as hacky as it is now, i'd prefer to keep it separate. So in the first step, it wouldn't go in. |
| 128 | 21:29:07 <RoanKattouw> I think of those two as sides of the same coin, they're both part of how a notification type is defined |
| 129 | 21:29:42 <RoanKattouw> Re mentions, legoktm has a suggestion to introduce a parser function for those |
| 130 | 21:29:49 <TimStarling> what is hacky about it? |
| 131 | 21:29:52 <RoanKattouw> (will find link) |
| 132 | 21:30:40 * TimStarling is finding the relevant hacky code now |
| 133 | 21:31:12 <DanielK_WMDE__> RoanKattouw: ah, so you think it doesn't make sense to split detection from delivery, since they are logically bount to the same event type. fair enough. delivery/presentation should be separate though - and should be fully implemented in core, i believe. |
| 134 | 21:31:24 <matt_flaschen> Whether one particular notification is generated in core is a side issue. That can easily and non-awkwardly be left for last if we wanted to move most stuff to core. |
| 135 | 21:31:50 <RoanKattouw> TimStarling: DiscussionParser.php in Echo |
| 136 | 21:31:56 <TimStarling> yeah, I found it |
| 137 | 21:31:58 <matt_flaschen> DanielK_WMDE__, I think you mean "split detection from routing"? |
| 138 | 21:32:02 <DanielK_WMDE__> RoanKattouw: then the question is just, which of the event types in Echo should be in core, and which don't need to be. |
| 139 | 21:32:05 <DanielK_WMDE__> can we frame it like that? |
| 140 | 21:32:23 <RoanKattouw> DanielK_WMDE__: Yes, exactly. And I think you are also missing the backend/storage/model as a part that I think should definitely be in core |
| 141 | 21:32:35 <RoanKattouw> Routing is just part of the notif definition IMO |
| 142 | 21:32:45 <DanielK_WMDE__> matt_flaschen, RoanKattouw: right, sorry. it's "split detection from routing" that perhaps isn't needed, of course. |
| 143 | 21:32:47 <TimStarling> it's not terrible, it gets the link list from a ParserOutput, it's not running regexes over the text (not for mentions anyway) |
| 144 | 21:33:24 <quiddity> TimStarling, one longterm plan to fix/replace the hacky version, is detailed at https://www.mediawiki.org/wiki/User:Legoktm/pings |
| 145 | 21:33:29 <RoanKattouw> Flow adds notifications about Flow replies, for example, so it needs to do both detection (only it knows when new Flow replies are created) and routing (only it knows who that reply was in response to, and which users have watchlisted the relevant topic) |
| 146 | 21:33:33 <robla> #info 14:32:02 DanielK_WMDE: then the question is just, which of the event types in Echo should be in core, and which don't need to be. RoanKattouw: Yes, exactly.[...] |
| 147 | 21:33:49 <DanielK_WMDE__> RoanKattouw: model, yes. storage... i guess you are right. i'd love to keep that out, but that would leave core with only immediate email notifications or some such nonsense. |
| 148 | 21:33:52 <RoanKattouw> robla: Uhm.... that's not what I said |
| 149 | 21:34:12 <robla> #info 14:33:53 <RoanKattouw> robla: Uhm.... that's not what I said |
| 150 | 21:34:13 <RoanKattouw> Well in fairness core has only immediate email notifications now |
| 151 | 21:34:21 <matt_flaschen> # info That's only one of the questions. There's also what parts of Echo framework and UI to move to core. |
| 152 | 21:34:28 <matt_flaschen> #info That's only one of the questions. There's also what parts of Echo framework and UI to move to core. |
| 153 | 21:34:55 <matt_flaschen> I favor moving everything, except possibly some notification types. |
| 154 | 21:34:55 <RoanKattouw> robla: Sorry, apparently that *is* what I said, but I was really responding to an earlier comment of Daniel's and he made his other comment while I was typing. Sorry. |
| 155 | 21:35:03 <DanielK_WMDE__> RoanKattouw: yea. maybe enough as a basline, and let the rest be optional? |
| 156 | 21:35:12 <RoanKattouw> "exactly" was re "bound to the same type" |
| 157 | 21:35:21 <RoanKattouw> Yeah, I could see that work |
| 158 | 21:35:37 <RoanKattouw> I think core needs to have all the APIs for extensions to be able to register, emit and route (to users) notifications |
| 159 | 21:35:57 <RoanKattouw> Pretty much everything else can be pluggable although a minimally useful implementation should probably be provided |
| 160 | 21:36:07 <DanielK_WMDE__> yes, that's all the "interface" stuff i was talking about |
| 161 | 21:36:20 <RoanKattouw> OK, right |
| 162 | 21:36:29 <matt_flaschen> RoanKattouw, so you favor having the real storage and query APIs outside of core, as an implementation of a pluggable component |
| 163 | 21:36:30 <matt_flaschen> ? |
| 164 | 21:36:32 <DanielK_WMDE__> perhaps it's better to call it "infrastructure" |
| 165 | 21:36:39 <DanielK_WMDE__> (as opposed to specific event types) |
| 166 | 21:36:41 <RoanKattouw> matt_flaschen: No strong opinions about that |
| 167 | 21:36:54 <RoanKattouw> I could go with that, but I could also go with having at least some of that stuff in core |
| 168 | 21:36:57 <RoanKattouw> Storage, for instance |
| 169 | 21:38:28 <TimStarling> trying to count people on each side here... |
| 170 | 21:39:02 * robla is glad TimStarling is doing the counting, because he's lost track |
| 171 | 21:39:07 <DanielK_WMDE__> RoanKattouw: it seems to me that storage is bound to a specific type of selivery/notification. (trivial) email or SMS needs none. |
| 172 | 21:39:37 <DanielK_WMDE__> RoanKattouw: can the storage system really be abstracted from the needs of the delivery mechanism? |
| 173 | 21:39:43 <RoanKattouw> DanielK_WMDE__: To some extent maybe, but I also don't want a world where every delivery plugin needs to provide its own storage |
| 174 | 21:39:55 <matt_flaschen> DanielK_WMDE__, it's true that trivial fire-and-forget unbundled delivery does not need storage (if there's no *other* delivery that does), but that's a very strong limitation that we probably don't want. |
| 175 | 21:39:58 <DanielK_WMDE__> TimStarling: can you define the sides? |
| 176 | 21:40:16 <RoanKattouw> Hmm but that's a fair comment, we have some stuff in our storage layer currently that's pretty specific to the delivery plugin |
| 177 | 21:40:22 <TimStarling> essentially small coreecho versus large coreecho |
| 178 | 21:40:23 * robla appreciates DanielK_WMDE__ asking that question :-) |
| 179 | 21:40:26 <RoanKattouw> Although some of that is in fact implemented as separate tables |
| 180 | 21:40:47 <SMalyshev> so storage can be a service which the specific delivery mechanism can opt to use or not use |
| 181 | 21:40:56 <TimStarling> the large coreecho side would put presentation, detection, etc. in core |
| 182 | 21:41:00 <DanielK_WMDE__> matt_flaschen: my question is if the mechanisms that do need storage can all use the same storage interface. i kind of doubt it. you would have to anticipate all kinds of queries the delivery mechanism will want to make. |
| 183 | 21:41:04 <TimStarling> perhaps even the entire echo extension |
| 184 | 21:41:21 <TimStarling> just get rid of that extension, provide all functionality in core, even the cross-wiki stuff |
| 185 | 21:41:48 <robla> #info 14:39:58 <DanielK_WMDE__> TimStarling: can you define the sides <TimStarling> essentially small coreecho versus large coreecho |
| 186 | 21:41:51 <TimStarling> the small coreecho side would have an interface and basic or null implementation in core |
| 187 | 21:41:55 <DanielK_WMDE__> SMalyshev: the storage interface would have to be very generic for that to work. very generic means no optimizations |
| 188 | 21:42:17 <DanielK_WMDE__> TimStarling: i see a continuum rather than sides |
| 189 | 21:42:22 <TimStarling> and the Echo extension would continue to exist, providing some of the features it currently provides, in terms of display, detection, etc. |
| 190 | 21:42:23 <robla> #info 14:40:57 <TimStarling> the large coreecho side would put presentation, detection, etc. in core |
| 191 | 21:42:29 <RoanKattouw> DanielK_WMDE__: I think a lot of the delivery-specific data can be in extra tables. We already have that for email bundling, there's an extra table mapping IDs to additional data |
| 192 | 21:42:30 <DanielK_WMDE__> so better sort than count :) |
| 193 | 21:42:57 <robla> #info 14:41:52 <TimStarling> the small coreecho side would have an interface and basic or null implementation in core |
| 194 | 21:43:23 <SMalyshev> DanielK_WMDE__: true, well, if service itself is pluggable then it also can be customized, I think the decision lies in whether we can write an interface that is useful and generic enough. Read: need specific usecases :) |
| 195 | 21:43:32 <DanielK_WMDE__> TimStarling: so the large coreecho would cover all types of notifications that Echo itself currently covers? |
| 196 | 21:43:39 <TimStarling> on the small core side I think is DanielK_WMDE__, mooeypoo |
| 197 | 21:43:53 <TimStarling> on the large core side: matt_flaschen, tgr, myself |
| 198 | 21:44:04 <matt_flaschen> DanielK_WMDE__, well TimStarling said the large could only have presentation, delivery, etc., not necessarily all notif-generating code. I agree with that. |
| 199 | 21:44:05 <TimStarling> and RoanKattouw is on the fence |
| 200 | 21:44:39 <robla> maybe small is "figure out a workable general interface, and have everything use it" and large is "merge Echo into core, and figure out how to make it fit" |
| 201 | 21:44:41 <RoanKattouw> BTW note that as far as providing notification types (what you call "detection" and "routing") goes, Echo is already used by a lot of other extensions, like Flow, ContentTranslation, PageTriage, etc |
| 202 | 21:44:50 <DanielK_WMDE__> RoanKattouw: that sounds like we would need to expose quite a bit of implementation details (the db schema, in particular) for extensions to add on to. i find that awkward, but perhaps it's not to horrible. |
| 203 | 21:45:17 <tgr> I think everyone agrees on figuring out a workable general interface and having everything use it |
| 204 | 21:45:26 <TimStarling> DanielK_WMDE__: I'm not trying to assign a specific proposal to each camp |
| 205 | 21:45:33 <DanielK_WMDE__> matt_flaschen: then we are on the same page. we can then start to argue about individual event types :) |
| 206 | 21:45:56 <DanielK_WMDE__> #info <tgr> I think everyone agrees on figuring out a workable general interface and having everything use it |
| 207 | 21:46:15 <DanielK_WMDE__> tgr: can you say what those interfaces would be? like, a few service names or something? |
| 208 | 21:46:52 <matt_flaschen> DanielK_WMDE__, "expose quite a bit of implementation details (the db schema, in particular) for extensions to add on to.", hmm, why? |
| 209 | 21:47:00 <matt_flaschen> We don't let extensions talk directly to Echo DB now, why would we later? |
| 210 | 21:47:26 <matt_flaschen> Those other ones (Flow, etc.) just generate notifications. They don't deal with storage or framework. |
| 211 | 21:47:31 <robla> tgr: it seems to be about tradeoffs. would we force Echo into rearchitecting it before or after it's merged into core |
| 212 | 21:47:57 <matt_flaschen> robla, a lot of the rearchitecting only makes sense if we merge to core. |
| 213 | 21:48:03 <matt_flaschen> We *have* to use hooks unless it's in core. |
| 214 | 21:48:05 <DanielK_WMDE__> matt_flaschen: if i understood correctly, RoanKattouw was proposing that extra delivery mechanisms add their own tables, but link (read: join) them to the standard storage table. but maybe i misunderstood. |
| 215 | 21:48:21 <RoanKattouw> Yeah pretty much |
| 216 | 21:48:22 <matt_flaschen> DanielK_WMDE__, oh, yeah, I thiought you were responding to something else. |
| 217 | 21:48:28 <RoanKattouw> The Echo table handling email bundling does that |
| 218 | 21:48:33 <tgr> DanielK_WMDE__: a service to queue objects which implement some EchoEvent interface (and support serialization), a service to map event objects to callbacks which route events to users, and something about presentation although I expect things will break down there and alternative extensions will just have to reimplement that part |
| 219 | 21:48:50 <TimStarling> <RoanKattouw> I have no strong opinions on whether presentation/rendering of notifs is moved fully from Echo to core or not. |
| 220 | 21:49:07 <TimStarling> ^ that is why I put RoanKattouw in between, since I think that is one differentiating question |
| 221 | 21:49:08 <RoanKattouw> robla: To clarify, I think matt_flaschen means that "once this code moves to core, it can and should be rearchitected to no longer use extension infra like hooks" |
| 222 | 21:49:51 <tgr> IMO web notifications need to be part of the default MediaWiki experience and I don't like the idea of relying on the tarball too much, not everyone uses that |
| 223 | 21:50:10 <tgr> people might install MediaWiki via an OS package or a Bitnami VM and whatnot |
| 224 | 21:50:30 <tgr> and they should not end up with some barebones placeholder thing for notifications |
| 225 | 21:50:47 <tgr> putting essential stuff into an extension just gives the wrong message |
| 226 | 21:50:50 <matt_flaschen> tgr, it's important to distinguish user location (which I think people here are calling routing) and delivery. |
| 227 | 21:51:00 <matt_flaschen> Delivery is how they actually get it (web UI, email, SMS, slack). |
| 228 | 21:51:16 <TimStarling> matt_flaschen: are you proposing to implement this? |
| 229 | 21:51:24 <matt_flaschen> Routing/user location is how we determine who to send it to (someone posted in this Flow discussion, who is notified). |
| 230 | 21:51:28 <DanielK_WMDE__> #info <DanielK_WMDE__> can you say what those interfaces would be? <tgr> a service to queue objects which implement some EchoEvent interface (and support serialization), a service to map event objects to callbacks which route events to users, and something about presentation although I expect things will break down there |
| 231 | 21:51:39 <matt_flaschen> TimStarling, I'm responding to tgr's list of services and noting it needs refinement. |
| 232 | 21:51:52 <matt_flaschen> "a service to queue objects [...]" |
| 233 | 21:52:05 <TimStarling> yeah, and I'm trying to step back a bit and extract action items since we're almost out of time |
| 234 | 21:52:26 <DanielK_WMDE__> #info <matt_flaschen> tgr, it's important to distinguish user location (which I think people here are calling routing) and delivery. |
| 235 | 21:52:29 <TimStarling> I mean are you going to implement the whole project, move echo to core? |
| 236 | 21:52:53 <matt_flaschen> TimStarling, I can work on it if we a. decide to do it b. Collaboration team decides to resource it. |
| 237 | 21:52:59 <mooeypoo> tgr, but even if notifications are part of core (and I agree they should be) that doesn't go against making core have a minimalist usage, and letting Echo do the full **specific** implementation |
| 238 | 21:53:27 <TimStarling> as I'm trying to say with my camp count, we have a bit of a deadlock |
| 239 | 21:53:53 <TimStarling> but implementors get precedence over commentators when it comes to design |
| 240 | 21:54:13 <TimStarling> that is one procedural way out of the deadlock |
| 241 | 21:54:13 <robla> I suppose an action item out of this is to define what the two "camps" are in the rfc |
| 242 | 21:54:31 <SMalyshev> maybe we should start with designing (not implementing yet) the generic interfaces/services, agreeing on them and then seeing how much of Echo is in/out |
| 243 | 21:54:56 <TimStarling> instead of an open design discussion, you can have a design team and a review |
| 244 | 21:54:56 <SMalyshev> and that would decide whether we need all of it or only a little of it |
| 245 | 21:55:08 <matt_flaschen> I'm not committing right now to work on it. |
| 246 | 21:55:23 <mooeypoo> SMalyshev, I agree, I think it's worth taking a step back and seeing what core should have and then go back to whether it means getting all of echo, parts of echo, or something in between. |
| 247 | 21:55:47 <robla> TimStarling: I think it's not a good idea to press people for action items, given both brion and legoktm are not here (legoktm was the author of this, brion the shepherd) |
| 248 | 21:56:07 <DanielK_WMDE__> TimStarling: i don't think there's a deadlock - we all agree the infrastructure should move into core, and probably (most of) presentation. |
| 249 | 21:56:08 <SMalyshev> yeah, instead of saying "how much Echo we take", saying "how much we need" and the looking how much of that is in Echo |
| 250 | 21:56:31 <mooeypoo> SMalyshev, +1 |
| 251 | 21:56:34 <DanielK_WMDE__> TimStarling: whether all event types are covered in core don't impact the engineering much. it's really a packaging decision,. |
| 252 | 21:56:39 <Scott_WUaS> (Thank you all for this good work!!! Cheers) |
| 253 | 21:57:12 <robla> #action robla define next steps in the RFC |
| 254 | 21:58:37 <robla> TimStarling: I agree with you about "implementors get precedence over commentators when it comes to design" |
| 255 | 21:58:49 <DanielK_WMDE__> hm, *do* we all agree that the infrastructure should go into core? |
| 256 | 21:59:11 <robla> DanielK_WMDE__: I think we have to agree to take that question to the Phab task |
| 257 | 21:59:22 <TimStarling> DanielK_WMDE__: that is just the definition of infrastructure |
| 258 | 21:59:49 <SMalyshev> DanielK_WMDE__: I think the question is *what* is the infrastructure :) |
| 259 | 22:00:03 <robla> ok....about to hit #endmeeting in 30 seconds |
| 260 | 22:00:28 * robla awaits getting tackled at his desk to prevent that |
| 261 | 22:00:43 <robla> nope....ok, great discussion! :-) |
| 262 | 22:00:49 <robla> #endmeeting |
Other meetings
| Architecture meetings | ||
|---|---|---|
| 13:00 PT ArchCom Planning Meetings | upcoming | all since 2016-03-30 |
| 14:00 PT ArchCom-RFC Meetings | upcoming | all since 2015-09-09 |
| Architecture meetings | ||
|---|---|---|
| 13:00 PT ArchCom Planning Meetings | upcoming | all since 2016-03-30 |
| 14:00 PT ArchCom-RFC Meetings | upcoming | all since 2015-09-09 |