Page MenuHomePhabricator
Paste P3638

ArchCom-RFC-2016W30-irc-E251.txt
ActivePublic

Authored by RobLa-WMF on Aug 3 2016, 10:06 PM.
21:02:17 <robla> #startmeeting ArchCom RFC Meeting W31: Notifications in core E251
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.
21:02:17 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:17 <wm-labs-meetbot`> The meeting name has been set to 'archcom_rfc_meeting_w31__notifications_in_core_e251'
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/
21:03:07 <robla> #link https://phabricator.wikimedia.org/T128351
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
21:04:02 <stashbot> T128351: RfC: Notifications in core - https://phabricator.wikimedia.org/T128351
21:04:36 <robla> brion documented the choice that he was hoping we'd be able to settle on this week
21:05:10 <robla> I think we can declare this discussion a field narrowing discussion where we clarify what options we have
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?
21:07:08 <robla> thoughts?
21:07:41 <bd808> The talk of inventing a new interface seems strange to me.
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"?
21:07:49 <Scott_WUaS> HI!
21:08:01 <matt_flaschen> https://phabricator.wikimedia.org/T128351#2500149
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").
21:08:58 <robla> matt_flaschen: yup, that's the documentation I was referring to
21:09:02 <DanielK_WMDE__> bd808: you want to keep using hooks?
21:09:20 <matt_flaschen> But, other people on Collaboration team such as mooeypoo have different views.
21:09:31 <bd808> DanielK_WMDE__: no, there would be no need for hooks into core if integrated
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
21:09:41 <mooeypoo> r it) and there are a few more of these.
21:09:48 <bd808> but maybe that was where I got confused
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.
21:10:46 <tgr> so the concern is that Echo is hard to install / administer for third parties?
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.
21:11:01 <tgr> a supposed MW core into which Echo has fully been merged, I mean
21:11:02 <matt_flaschen> tgr, it's extremely easy to install in my opinion.
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"
21:11:09 <RoanKattouw> I don't think Echo is hard to install at all
21:11:21 <DanielK_WMDE__> bd808: i just want to know what that method would look like
21:11:22 <mooeypoo> matt_flaschen, yes, I think ideally those shouldn't be there either, but that's a different issue :P
21:11:35 <bd808> vagrant role enable echo; vagrant provision -- ;)
21:11:35 <matt_flaschen> The only real benefit I see to merging into core is to fully unify all notifications.
21:11:35 <tgr> I don't really see the disadvantage of shipping core functionality that most people won't need
21:11:50 <tgr> we have WikiMap in core and whatnot
21:11:50 <matt_flaschen> No more watchlist emails/password reset emails/whatever that look weirdly different from other notifiations (Echo).
21:12:02 <matt_flaschen> All notifications should act and look the same.
21:12:08 <DanielK_WMDE__> tgr: depends on how much it adds to the monolith...
21:12:10 <RoanKattouw> There are issues with /fully/ integrating enotif and Echo
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.
21:12:26 <matt_flaschen> Sometimes, yeah, but not often.
21:12:27 <RoanKattouw> But I agree that email consistency would probably be easier to achieve
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)
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.
21:13:35 <RoanKattouw> Yes, that's largely what I was getting a
21:13:36 <RoanKattouw> t
21:13:50 <RoanKattouw> I think there'd be problems making them actual Echo notifs, but they could use the same rendering stack
21:13:56 <tgr> I think making MW core less monolitic would be great, but extensions are not necessarily the right tool for that
21:13:57 <matt_flaschen> But things like $wgEnotifUserTalk could be fully unified.
21:14:08 <matt_flaschen> (Instead of replaced by an extension)
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
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.
21:14:27 <TimStarling> mooeypoo: conceptually, extensions are optional, if you have a required extension then it is a library, not an extension
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.
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
21:15:37 <matt_flaschen> "random other extensions such as EducationProgram or ContentTranslation wouldn't have to depend on Echo"
21:15:40 <matt_flaschen> What's wrong with them doing so?
21:15:49 <matt_flaschen> Also, it can be a soft dependency already.
21:15:53 <RoanKattouw> Yes, that's true
21:16:06 <RoanKattouw> It's more convenient if there's a core API, is what I meant
21:16:35 <bd808> Extensions depending on each other can get pretty sticky
21:16:44 <robla> is notifying other users about activity at the heart of what MediaWiki's job is?
21:16:48 <bd808> lots of ways that it becomes difficult to setup or upgrade things
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.
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...)
21:17:16 <matt_flaschen> robla, I think it's pretty essential functionality, though not necessarily Echo-style notifications, as RoanKattouw said.
21:17:24 <mooeypoo> ^ agreed with matt_flaschen
21:17:24 <bd808> robla: For me personally, I think change notification is pretty core to collaboration
21:17:26 <matt_flaschen> But even core has at least one Echo-style notification (user talk notifications).
21:17:56 <matt_flaschen> And maybe would have more if there were a better notification framework in core.
21:18:32 <tgr> yes, notifications are at the heart of any social software
21:18:37 <TimStarling> it probably would have more
21:18:46 <DanielK_WMDE__> I think wwe should have implementations of delivery in core, but perhaps only very basic routing and detection.
21:18:47 <matt_flaschen> mooeypoo, do you want to describe your thoughts on the line of what should be in core?
21:19:15 <tgr> and the current UX is very fractured (Echo, core mails, orange bar of doom in different varieties)
21:19:21 <TimStarling> we should have notification for (non-user) talk page replies in core
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.
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
21:19:49 <TimStarling> echo at least has a notification when someone mentions your name, which is really essential for everyone
21:19:56 <DanielK_WMDE__> tgr: +1
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)
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
21:20:18 <RoanKattouw> that renders it) should be in core IMO
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.
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
21:21:14 <DanielK_WMDE__> RoanKattouw: that actually sounds like we agree... where do you think we do not?
21:21:31 <matt_flaschen> mooeypoo, I'm concerned that we tend to change API pretty tightly in coordination with UI.
21:21:38 <matt_flaschen> How will that work if the API is in core, but the fancy UI is in Echo.
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.
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
21:22:40 <tgr> you can do it for emails, for example, even though the mail sending code is part of core
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
21:23:06 <tgr> and MediaWikiServices is good groundwork for making it possible in a non-horrible way
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" ;)
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.
21:23:35 <matt_flaschen> (Replaceable by third-party components).
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.
21:23:53 <RoanKattouw> What part of the routing logic do you think does not belong in core?
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.
21:24:02 <tgr> I agree with TimStarling that libraries are a better concept for separating stuff and making it easy to replace
21:24:09 <bd808> they won't
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.
21:24:37 <bd808> I could see an extension that did mobile push
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.
21:25:01 <matt_flaschen> DanielK_WMDE__, is that what you mean by "detection"?
21:25:02 <TimStarling> supposing we merge most or all of echo into core, producing "coreecho"
21:25:14 <DanielK_WMDE__> matt_flaschen: yes, that's what i'm thinking should be done.
21:25:18 <robla> #info discussion about the separation of detection, routing, and delivery as three portions of a notification framework
21:25:19 <TimStarling> then coreecho can be the hookable thing, modified by extensions
21:25:22 <tgr> bd808: mobile push, SMS, Slack integration... I don't think it that unlikely at all
21:25:35 <bd808> yeah
21:25:37 <TimStarling> extensions then have a richer framework to work on top of
21:25:59 <matt_flaschen> tgr, there's a difference between adding an alternative delivery and replacing an existing component.
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.
21:26:58 <tgr> fair point. There seems to be very little reason to replace the existing functionality of Echo
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
21:27:21 <mooeypoo> ses of the system.
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)?
21:27:34 <TimStarling> DanielK_WMDE__: I think those two things specifically could be part of core
21:28:16 <TimStarling> I am basically favouring a larger version of coreecho
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)?
21:28:29 <TimStarling> not the interface-centric versions of this proposal
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
21:28:42 <RoanKattouw> I see
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.
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
21:29:42 <RoanKattouw> Re mentions, legoktm has a suggestion to introduce a parser function for those
21:29:49 <TimStarling> what is hacky about it?
21:29:52 <RoanKattouw> (will find link)
21:30:40 * TimStarling is finding the relevant hacky code now
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.
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.
21:31:50 <RoanKattouw> TimStarling: DiscussionParser.php in Echo
21:31:56 <TimStarling> yeah, I found it
21:31:58 <matt_flaschen> DanielK_WMDE__, I think you mean "split detection from routing"?
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.
21:32:05 <DanielK_WMDE__> can we frame it like that?
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
21:32:35 <RoanKattouw> Routing is just part of the notif definition IMO
21:32:45 <DanielK_WMDE__> matt_flaschen, RoanKattouw: right, sorry. it's "split detection from routing" that perhaps isn't needed, of course.
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)
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
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)
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.[...]
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.
21:33:52 <RoanKattouw> robla: Uhm.... that's not what I said
21:34:12 <robla> #info 14:33:53 <RoanKattouw> robla: Uhm.... that's not what I said
21:34:13 <RoanKattouw> Well in fairness core has only immediate email notifications now
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.
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.
21:34:55 <matt_flaschen> I favor moving everything, except possibly some notification types.
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.
21:35:03 <DanielK_WMDE__> RoanKattouw: yea. maybe enough as a basline, and let the rest be optional?
21:35:12 <RoanKattouw> "exactly" was re "bound to the same type"
21:35:21 <RoanKattouw> Yeah, I could see that work
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
21:35:57 <RoanKattouw> Pretty much everything else can be pluggable although a minimally useful implementation should probably be provided
21:36:07 <DanielK_WMDE__> yes, that's all the "interface" stuff i was talking about
21:36:20 <RoanKattouw> OK, right
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
21:36:30 <matt_flaschen> ?
21:36:32 <DanielK_WMDE__> perhaps it's better to call it "infrastructure"
21:36:39 <DanielK_WMDE__> (as opposed to specific event types)
21:36:41 <RoanKattouw> matt_flaschen: No strong opinions about that
21:36:54 <RoanKattouw> I could go with that, but I could also go with having at least some of that stuff in core
21:36:57 <RoanKattouw> Storage, for instance
21:38:28 <TimStarling> trying to count people on each side here...
21:39:02 * robla is glad TimStarling is doing the counting, because he's lost track
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.
21:39:37 <DanielK_WMDE__> RoanKattouw: can the storage system really be abstracted from the needs of the delivery mechanism?
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
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.
21:39:58 <DanielK_WMDE__> TimStarling: can you define the sides?
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
21:40:22 <TimStarling> essentially small coreecho versus large coreecho
21:40:23 * robla appreciates DanielK_WMDE__ asking that question :-)
21:40:26 <RoanKattouw> Although some of that is in fact implemented as separate tables
21:40:47 <SMalyshev> so storage can be a service which the specific delivery mechanism can opt to use or not use
21:40:56 <TimStarling> the large coreecho side would put presentation, detection, etc. in core
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.
21:41:04 <TimStarling> perhaps even the entire echo extension
21:41:21 <TimStarling> just get rid of that extension, provide all functionality in core, even the cross-wiki stuff
21:41:48 <robla> #info 14:39:58 <DanielK_WMDE__> TimStarling: can you define the sides <TimStarling> essentially small coreecho versus large coreecho
21:41:51 <TimStarling> the small coreecho side would have an interface and basic or null implementation in core
21:41:55 <DanielK_WMDE__> SMalyshev: the storage interface would have to be very generic for that to work. very generic means no optimizations
21:42:17 <DanielK_WMDE__> TimStarling: i see a continuum rather than sides
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.
21:42:23 <robla> #info 14:40:57 <TimStarling> the large coreecho side would put presentation, detection, etc. in core
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
21:42:30 <DanielK_WMDE__> so better sort than count :)
21:42:57 <robla> #info 14:41:52 <TimStarling> the small coreecho side would have an interface and basic or null implementation in core
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 :)
21:43:32 <DanielK_WMDE__> TimStarling: so the large coreecho would cover all types of notifications that Echo itself currently covers?
21:43:39 <TimStarling> on the small core side I think is DanielK_WMDE__, mooeypoo
21:43:53 <TimStarling> on the large core side: matt_flaschen, tgr, myself
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.
21:44:05 <TimStarling> and RoanKattouw is on the fence
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"
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
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.
21:45:17 <tgr> I think everyone agrees on figuring out a workable general interface and having everything use it
21:45:26 <TimStarling> DanielK_WMDE__: I'm not trying to assign a specific proposal to each camp
21:45:33 <DanielK_WMDE__> matt_flaschen: then we are on the same page. we can then start to argue about individual event types :)
21:45:56 <DanielK_WMDE__> #info <tgr> I think everyone agrees on figuring out a workable general interface and having everything use it
21:46:15 <DanielK_WMDE__> tgr: can you say what those interfaces would be? like, a few service names or something?
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?
21:47:00 <matt_flaschen> We don't let extensions talk directly to Echo DB now, why would we later?
21:47:26 <matt_flaschen> Those other ones (Flow, etc.) just generate notifications. They don't deal with storage or framework.
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
21:47:57 <matt_flaschen> robla, a lot of the rearchitecting only makes sense if we merge to core.
21:48:03 <matt_flaschen> We *have* to use hooks unless it's in core.
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.
21:48:21 <RoanKattouw> Yeah pretty much
21:48:22 <matt_flaschen> DanielK_WMDE__, oh, yeah, I thiought you were responding to something else.
21:48:28 <RoanKattouw> The Echo table handling email bundling does that
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
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.
21:49:07 <TimStarling> ^ that is why I put RoanKattouw in between, since I think that is one differentiating question
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"
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
21:50:10 <tgr> people might install MediaWiki via an OS package or a Bitnami VM and whatnot
21:50:30 <tgr> and they should not end up with some barebones placeholder thing for notifications
21:50:47 <tgr> putting essential stuff into an extension just gives the wrong message
21:50:50 <matt_flaschen> tgr, it's important to distinguish user location (which I think people here are calling routing) and delivery.
21:51:00 <matt_flaschen> Delivery is how they actually get it (web UI, email, SMS, slack).
21:51:16 <TimStarling> matt_flaschen: are you proposing to implement this?
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).
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
21:51:39 <matt_flaschen> TimStarling, I'm responding to tgr's list of services and noting it needs refinement.
21:51:52 <matt_flaschen> "a service to queue objects [...]"
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
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.
21:52:29 <TimStarling> I mean are you going to implement the whole project, move echo to core?
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.
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
21:53:27 <TimStarling> as I'm trying to say with my camp count, we have a bit of a deadlock
21:53:53 <TimStarling> but implementors get precedence over commentators when it comes to design
21:54:13 <TimStarling> that is one procedural way out of the deadlock
21:54:13 <robla> I suppose an action item out of this is to define what the two "camps" are in the rfc
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
21:54:56 <TimStarling> instead of an open design discussion, you can have a design team and a review
21:54:56 <SMalyshev> and that would decide whether we need all of it or only a little of it
21:55:08 <matt_flaschen> I'm not committing right now to work on it.
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.
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)
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.
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
21:56:31 <mooeypoo> SMalyshev, +1
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,.
21:56:39 <Scott_WUaS> (Thank you all for this good work!!! Cheers)
21:57:12 <robla> #action robla define next steps in the RFC
21:58:37 <robla> TimStarling: I agree with you about "implementors get precedence over commentators when it comes to design"
21:58:49 <DanielK_WMDE__> hm, *do* we all agree that the infrastructure should go into core?
21:59:11 <robla> DanielK_WMDE__: I think we have to agree to take that question to the Phab task
21:59:22 <TimStarling> DanielK_WMDE__: that is just the definition of infrastructure
21:59:49 <SMalyshev> DanielK_WMDE__: I think the question is *what* is the infrastructure :)
22:00:03 <robla> ok....about to hit #endmeeting in 30 seconds
22:00:28 * robla awaits getting tackled at his desk to prevent that
22:00:43 <robla> nope....ok, great discussion! :-)
22:00:49 <robla> #endmeeting