[03:28:33] AaronSchulz: can we start referring to the multi-DC project as 'MDC', for short? 'multi-DC' is awkward to type and 'availability' is too broad [03:29:19] This is clearly a question of immense consequence, so feel free to think it over first [04:25:59] The Mozilla Developer Center! [04:26:05] https://en.wikipedia.org/wiki/MDC [04:27:51] Or MDC Vacuum Products, LLC [18:42:51] legoktm: did you see the discussion starting at https://phabricator.wikimedia.org/T116786#1799351? [18:43:10] TL;DR do you think EventRelayer is a better choice for producing these events? [18:44:20] AaronSchulz: ^^^ [18:44:54] urandom: I haven't, /me reads [18:46:01] urandom: what is EventRelayer? [18:46:36] legoktm: indeed :) [18:46:44] https://doc.wikimedia.org/mediawiki-core/master/php/classEventRelayer.html#details [18:47:18] i think it's used to propagate events to remote DCs, to update remote caches [18:48:50] legoktm: what's not obvious to me yet is, if i had an implementation of EventRelayer, what would i do with it? [18:49:47] oh, right. [18:49:57] I'm not really sure how it's supposed to be used either. [18:51:02] reparsing the line in RCFeedEngine would suck. [18:51:09] yes [18:51:18] i wasn't seriously suggesting that [18:54:00] i don't think it's a problem to include the topic, and to POST all events to the same resource, but EventRelayer *does* receive a structured payload, it would be less of an issue in this regard [18:55:22] we could modify RCFeedEngine to accept additonal structured data or pass in the original RC object entirely? [18:55:27] but i'm guessing that other parts of mw would have to be made EventRelayer-capable [18:55:54] legoktm: yeah [18:56:11] you mean, do the serialization to string in the engines? [18:56:51] that's breaking, isn't it? [18:57:04] do people implement their own engines? [18:57:53] legoktm: or did i misread the 'or' in that statement? [19:00:25] it would be breaking, but afaik all the engines are implemented in core [19:01:05] hm, I think it would need to still happen in the formatter [19:01:20] the whole point of the IRC one is to build the string, that's all that needs to be serialized [19:01:39] I was thinking we could just add another parameter [19:01:48] public function send( array $feed, $line, $stuff ); [19:02:00] yeah [19:02:05] that seems a little clunky [19:02:35] would definitely show as the after-thought it is [19:04:54] yeah...this interface was primarily designed for IRC and rcstream, and nothing else :P [19:18:27] legoktm: so to summarize, this interface is very much geared toward sending formatted strings, and fixing it would be breaking [19:19:04] it would be nice to evaluate this next to what it would take to use EventRelayer, but it's not clear to me what that would entail [19:20:10] actually, you could almost make RecentChange use EventRelayer *instead* of a rc formatter/engine [19:20:42] relay the RC itself, and then use the formatter internally [19:24:24] urandom: yeah, but I don't think making a breaking change here is a big deal [19:25:58] legoktm: what do you think about that, then? having each feed be implemented with an EventRelayer, with existing implementations internally making use of the existing formatter? [19:27:19] that would lock the choice of formatter to an ER implementation [19:27:41] but maybe they are in practice anyway [20:02:30] legoktm: actually, this might be a little bit bigger of a problem than i originally guessed [20:03:16] we'll want to generate events for what i assume is some subset of all possible RCs, but i don't think there is any way to filter [20:04:33] maybe return null from the formatter for a change that isn't of interest? [22:02:17] RFC meeting starting now in #wikimedia-office regarding "make Parser::getTargetLanguage aware of multilingual wikis" [23:08:34] "Foo is too complicated; let's add a LightweightFoo class that is like Foo, except not complicated" [23:08:45] result: more complexity [23:08:46] AaronSchulz: btw, have you had a chance to look at the job queue issues from earlier today? [23:09:01] We're still reverted at the moment. Per twentyafterfour [23:10:03] ori: no, that is not the proposal [23:10:29] the proposal is to define a specific subset of Foo's functionality [23:10:36] FooSubset [23:10:45] to have Foo delegate that functionality to FooSubset [23:11:03] and for things that need only what is in FooSubset to use it directly [23:12:08] I think I'd be happier talking about interface usability than complexity [23:12:39] on complexity you know we are poles apart [23:12:48] but on usability we have common ground [23:13:24] TimStarling: if you call Foo:something() , do you get a deprecation warning "use FooSubset::something() insetad" ? If not, I don't see how the subset is easier. [23:15:29] TimStarling: that would work if the plan was to make the current Title object be a subclass of a new class that would only have a few essential and well-designed methods [23:15:59] no, that wouldn't work [23:16:27] because you can only have one superclass but there are a lot of different things that Title does [23:17:58] spagewmf: the RFC does not propose deprecation [23:19:01] for someone who knows what they're doing they can pick the cleaner, narrower FooSubset, but unless we break MW so clients get and pass FooSubset, developers won't know to adapt [23:20:10] I would indeed want to address that by making Title do fewer things, but since that is a nonstarter in terms of getting consensus, I'll retreat to more solid ground, which is this argument: [23:21:05] for a proposal to be a good idea, it is not sufficient that it is clever in some Platonic, timeless way; it has to also be timely and practical. [23:21:33] this one isn't, because there is a lot of code-litter that could and should be cleaned up first [23:22:31] you could argue that there neither is prior to the other, but I think the cleanup must be prior because any conceptual innovation would be improved by being implemented against a simpler and tidier status quo [23:22:51] what specifically should be cleaned up? [23:23:54] for one: we should either get rid of TitleValue or do the work of making it replace Title in more places [23:24:19] it was introduced to the codebase with the understanding that the complexity it adds would be offset by increased simplicity in the places where it is used [23:24:28] that never really happened [23:24:46] you could probably rip it out without users being affected [23:24:47] that is the motivation for PageRecord though -- it turns out that a lot of Title users need something more than TitleValue [23:25:10] sure, but that suggests that TitleValue was the wrong idea [23:25:43] you're saying PageRecord should have all the TitleValue code? [23:26:00] instead of delegating to TitleValue? [23:27:00] that, or TitleValue should be extended so that those users of Title that need something more than TitleValue could use TitleValue [23:27:04] what about MediaWikiTitleCodec etc., should that depend on PageRecord? [23:28:29] well, I'm saying we should not attempt to answer these questions until we tidy things up [23:28:31] the idea was to make things like MediaWikiTitleCodec testable without having to mock the whole DB [23:28:34] we should remove Page too [23:29:21] let me look at the code for a sec, it's not hard to get specific [23:30:17] here's one: [23:31:03] Title::getTitleParser() and Title::getTitleFormatter() are both described as "B/C kludge: provide a TitleParser for use by Title. Ideally, Title would have no methods that need this. Avoid usage of this singleton by using TitleValue and the associated services when possible." [23:31:50] why don't we indeed make Title not have any methods that need this and then get rid of these two methods? [23:32:51] Wouldn't very basic things in Title need a parser and/or a formatter? [23:32:59] ->getPrefixedText() and newFromText() come to mind [23:33:46] Those are probably the most-used instance method and the most-used static method respectively [23:34:06] so migrate callers to use TitleValue [23:34:14] or get rid of TitleValue, if that is unfeasibly difficult [23:34:22] because in that case, it does not deliver on its promise [23:34:22] ok [23:34:30] Migrating callers would be enormously difficult [23:34:33] Well [23:34:38] No [23:34:47] It wouldn't be "difficult", it would just be a giant amount of work [23:34:54] so get rid of titlevalue [23:35:18] there is Title::newFromTitleValue() [23:36:23] I feel like I understand the desire to use value objects, but I don't remember having seen a use case that would be worth making such a massive breaking change [23:36:37] Maybe I've forgotten, because it's been a long time since I've been in a discussion about TitleValue [23:37:25] Title.php, L30, added 2014-01: @note Consider using a TitleValue object instead. TitleValue is more lightweight and does not rely on global state or the database [23:37:36] you can migrate from Title::newFromText($text) to Title::newFromTitleValue($this->titleParser->parseTitle($text)) [23:38:05] By myself I can come up with a few nebulous things like "it would probably make dealing with titles from other wikis easier", but maybe people who are in the thick of it have come up with more convincing things [23:38:08] T114394, Oct 1: "this RFC proposes to introduce: PageRecord: a lightweight data object for representing wiki pages. Rationale: Reduce usage of the Title object. Title is a heavy weight smart record with many dependencies, and tightly bound to the database layer. Replacing it with something more lightweight would improve modularity and testability." [23:38:09] Right [23:38:15] And I guess we could keep B/C aliases around for some time [23:39:25] (how do you even explain this to a new developer?) [23:39:28] with PageLookup it would presumably be: [23:40:04] "Hi, what's the difference between PageRecord and TitleValue?" "Easy: one is a lightweight variant of Title that is not so tightly bound to the database layer; the other is a lightweight variant of Title that is not so tightly bound to the database layer" [23:40:12] $this->pageLookup->find($this->titleParser->parseTitle($text)) [23:40:46] ori: I think I understand the difference, based on the names and my knowledge of the many things that Title does, but I agree that the things you quoted don't describe the difference well [23:41:40] I propose "ArticleItem" as the name for the class we introduce in 2016 to solve this problem [23:41:48] ori: "explain to developer" is impossible :-) Developers will access the first thing that gives them the object that has the method they need. [23:43:17] i.e. with PageLookup you are using PageRecord in some cases where you were using Title before [23:43:24] TimStarling: that's not bad, but no one will do it [23:43:46] sure they will [23:52:31] this whole thing reminds me of this great bit in Kafka's "The Trial": [23:52:34] "Moorland landscape," said the painter passing the picture to K. It showed two sickly trees, well separated from each other in dark grass. In the background there was a multi-coloured sunset. "That's nice," said K. "I'll buy it." K. expressed himself in this curt way without any thought, so he was glad when the painter did not take this amiss and picked up a second painting from the floor. [23:52:37] "This is a counterpart to the first picture," said the painter. Perhaps it had been intended as a counterpart, but there was not the slightest difference to be seen between it and the first picture, there were the trees, there the grass and there the sunset. But this was of little importance to K. "They are beautiful landscapes," he said, "I'll buy them both and hang them in my office." [23:52:40] "You seem to like this subject," said the painter, picking up a third painting, "good job I've still got another, similar picture here." The picture though, was not similar, rather it was exactly the same moorland landscape. The painter was fully exploiting this opportunity to sell off his old pictures. "I'll take this one too," said K. "How much do the three paintings cost?" "We can talk about that next time," said the painter [23:52:40] . [23:52:58] if you were saying this in 2014 I would be more receptive [23:53:14] you know I argued against this idea quite a lot at that time [23:53:36] but as far as I'm concerned, it was decided at that time, in the 2014 architecture summit [23:53:51] and there's no new information, the approach hasn't been disproven [23:54:13] yes, the benefits it could provide could still technically happen [23:54:18] i'm not holding my breath [23:54:26] it makes sense to carry on in one direction for a bit, doesn't it? [23:54:34] rather than reverting ourselves on alternate years? [23:55:01] it's always a good time to roll back a bad decision [23:55:10] that never falls out of fashion :) [23:56:30] but like I say, there's no evidence it was a bad decision, you're not giving me arguments I haven't heard before [23:56:35] I'm tempted to just troll Daniel by writing up an ArticleEntry RFC and claiming that any resemblance to PageRecord is merely apparent [23:57:52] well, there is one item of new evidence [23:58:15] you know, Alan Perlis once said that in the long run every program becomes rococo, then rubble. If we're in the rococo phase let's go all in [23:58:18] which is that the enthusiasm expressed at the 2014 arch summit has not actually translated to people writing code [23:58:37] yeah, that's pretty damning imo [23:59:14] Daniel obviously hasn't changed his mind, nor the WMDE folks [23:59:16] that doesn't necessarily condemn the current proposal, but it does mean it needs to be accompanied with some social initiative [23:59:32] with realistic targets and milestones [23:59:35] rather than vague hopes