Talk:Requests for comment/Third-party components

Logging / Monolog
The "devops sprint" being worked on by the Platform Core is hoping to produce an RFC on a revamp of the logging APIs and functionality in MediaWiki. There may be some synergy with that initiative if the fundamental idea of how best to integrate 3rd party code into the platform can get some attention. --BDavis (WMF) (talk) 03:53, 27 November 2013 (UTC)
 * The Wikimania Scholarship standalone application is using Monolog and will likely produce a udp2log compatible \Monolog\Handler implementation by the time it is released to production. --BDavis (WMF) (talk) 03:57, 27 November 2013 (UTC)


 * creates a proof of concept implementation for the Structured logging RFC that includes using a composer.json file in a subdirectory to allow using Composer to import and maintain third-party libraries within mediawiki-core. --BDavis (WMF) (talk) 18:26, 12 February 2014 (UTC)

Where it makes sense
If we want to use a third party component, I think there should be justification beyond "its shiny". If we have our own component, that works perfectly well, I see no reason to fix what isn't broken. Bawolff (talk) 02:35, 4 December 2013 (UTC)
 * I agree. For mail, I've added a link to a bug which has several dependencies and might be helped by a proper library. It would be useful to link bug reports which may be helped/receive a fresh look with a new framework. --Nemo 10:11, 1 January 2014 (UTC)
 * The RFC mentions in the rightmost columns what the advantages/disadvantages might be. This RFC is not advocating replacing all of MediaWiki with third-party components; it's just an attempt to consider the possibilities and see what might be worth replacing. Parent5446 (talk) 22:39, 7 March 2014 (UTC)

Why Swift Mailer?
Has a proper comparison been done between Swift Mailer and PHPMailer been done? Daniel Friesen (Dantman) (talk) 00:27, 9 December 2013 (UTC)


 * I'd be very interested in this too. I have only litte experience with SwiftMailer, but so far I found it very useful and easy to understand. But PHPMailer also sounds interesting. If integrating thidy-party components to MW becomes a real thing I'd love to help with this. --Osnard (talk) 08:46, 13 February 2014 (UTC)


 * Integrating third-party components is already a real thing, though mostly for a lot of JavaScript. This is to say, if you want to give it a try you can just submit a patch for SwiftMailer and then we would know better what the issues are with implementing it if any. Maybe SwiftMailer and PHPMailer are both good enough, in that case what will make one prevail over the other is just which is coded first for MediaWiki. :) --Nemo 20:39, 14 February 2014 (UTC)


 * This is not comprehensive, but Swift_Mailer seems to be a **lot** more robust. PHPMailer has everything packed into a few classes, whereas Swift_Mailer actually has a separation of concerns, with classes for attachments, transport types, etc. A result of this is that PHPMailer has two different functions for embedding multimedia: addEmbeddedImage for files and addStringEmbeddedImage for strings. Another example is that PHPMailer supports only two bodies for multipart messages, whereas Swift_Mailer will add in as many bodies as you tell it to since a body is wrapped in its own object. In addition, PHPMailer only really supports SMTP, whereas Swift_Mailer has an extensible transport architecture, and multiple transport providers. (And there's also plugins, and monolog integration, etc.) Parent5446 (talk) 22:56, 7 March 2014 (UTC)

CLDR
Do things like AntiSpoof fit somewhere here? It seems most of its content my be replaced by the ICU API, i.e. by some additional data/libraries in extension:CLDR. See 63217. --Nemo 22:29, 28 March 2014 (UTC)

Discuss next week?
I'm planning on having us talk about Ryan Lane's Requests for comment/MediaWiki libraries in an RfC review meeting next week, and it seems to me that it would be useful to discuss "Third-party components" in the same hour. Would you be available Monday or Tuesday afternoon for such a chat? Sharihareswara (WMF) (talk) 15:18, 23 April 2014 (UTC)
 * Afternoon in what timezone? Better give UTC hour ranges... --Nemo 15:23, 23 April 2014 (UTC)
 * I happen to know that Tyler does Eastern Time right now, so I figured vernacular was fine. :-) It's settled: we'll be discussing this RfC Tuesday 29 April, 2200-2300 UTC. Sharihareswara (WMF) (talk) 17:38, 25 April 2014 (UTC)
 * Summary of today's discussion: it sounds like we only want to replace an artisanal, homegrown MediaWiki component with an externally maintained library if the feature is complicated, upstream is friendly and responsive and aligned with us, and so on, on a case-by-case basis.
 * * Third-party components (sumanah, 22:43:16)
 * ** LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components (sumanah, 22:43:20)
 * ** Tyler Romeo's proposal (replacing some MW components with more widely used libraries, especially Symfony libraries) (sumanah, 22:43:26)
 * ** parent5446 is looking for feedback on the general concept.  (sumanah, 22:43:41)
 * ** LINK: https://www.mediawiki.org/wiki/Upstream_projects (sumanah, 22:56:08)
 * ** this seems like something that�ll be easier to treat once we have a consistent dependency manager :D (sumanah, 22:57:36)
 * ** we feel mixed about the general concept of choosing to reuse external stuff instead of writing it ourselves - depends on code quality, which you gotta take on a case-by-case basis (sumanah, 22:58:41)
 * ** part of the issue with the way we do things now is that, while being potentially superior along many vectors (performance, reliabilitiy, security), we seem to fall down on reusability, which is unfortunate (sumanah, 22:59:00)
 * ** also, we're more likely to be interested in a replacement if the feature is quite complicated, e.g., JS minification (sumanah, 22:59:52)
 * ** examples of good PHP code out there that's reusable: monolog, Symfony2 stuff (sumanah, 23:00:16)
 * Sharihareswara (WMF) (talk) 23:49, 29 April 2014 (UTC)
 * Full IRC log:


 * 22:43:10 #topic MediaWiki libraries
 * 22:43:16 #topic Third-party components
 * 22:43:20 #link https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components
 * 22:43:26 #info Tyler Romeo's proposal (replacing some MW components with more widely used libraries, especially Symfony libraries)
 * 22:43:39 it would be cumbersome to manually register all the dependencies of wikibase
 * 22:43:41 #info parent5446 is looking for feedback on the general concept.
 * 22:43:46 which requires a package manager :)
 * 22:44:17 I don't see any one replacement jumping out at me yet as "oh yes, let's do that replacement right now"
 * 22:44:19 Hence the advantage of discussing these two RFCs together
 * 22:44:24 bd808: yep
 * 22:44:41 but I like the idea. As parent5446 says: "other open source projects have created entire libraries that do the same thing as the MediaWiki components, except are better maintained and much more functional. This RFC aims to replace one or more MediaWiki components with third-party open source components."
 * 22:44:50 *nod*
 * 22:45:01  I don't think I am in favour of this general direction
 * 22:45:02 this seems like something that’ll be easier to treat once we have a consistent dependency manager :D
 * 22:45:06 hmm
 * 22:45:26  I like the idea of using a full mail library. But I don't like the replacement of WebRequest.
 * 22:45:29  when we maintain our own small libraries, we can make changes to them
 * 22:45:42  the more we use external libraries, the more we will be blocked waiting for upstream
 * 22:46:04  with our own code, we maintain some flexibility
 * 22:46:26  for complicated things like JS minification, sure, use an external library
 * 22:46:26 we can maintain local patches but that way lies madness
 * 22:46:35  but I don't think it makes sense for simple things like curl wrappers
 * 22:46:42 How are those other (external) libs hosted? Would managing them drastically increase the scope of what composer has to do?
 * 22:46:48 the more we use external libraries; the more we'll start running into libraries that pull in other libraries (which at worst are not compatible and at best are redundant)
 * 22:47:15 isn't this chain of logic the way to wheel reinvention hell?
 * 22:47:31 I wouldn't use the extreme as the norm
 * 22:47:41 wheel not reinvented here :)
 * 22:47:41 Not all libraries are dependency hell or hard to get things fixed upstream
 * 22:47:57 maybe one way to balance this is to actually do the kind of inventory that parent5446 has done every so often, and check ourselves
 * 22:48:03  I don't really believe in that phrase
 * 22:48:18  I think there's a difference between making a wheel and inventing a wheel
 * 22:48:38  having studied many wheels, a good engineer can make a wheel for a specific purpose without much difficulty
 * 22:48:40 Making a custom mail library when SwiftMailer already exists in re-inventing the wheel
 * 22:48:50  the same is true of libraries
 * 22:49:04 Is there a general-case question implied by that RFC? Or is it just a question of considering each possible replacement case-by-case?
 * 22:49:11 I agree with parent5446 that there are good externals and bad. We should only use the good ones. :)
 * 22:49:23 * andrewbogott doesn't know if relying on any one external library already involves overhead that isn't done yet
 * 22:49:26  "don't reinvent the wheel", taken literally, encourages study, not recycling
 * 22:50:00 as parent5446 says on the talkpage, "This RFC is not advocating replacing all of MediaWiki with third-party components; it's just an attempt to consider the possibilities and see what might be worth replacing."
 * 22:50:40 do we have anyone here who has maintained jQuery in core? I feel it is a good case study
 * 22:50:47 so it sounds like one principle is: the more complicated the kind of thing we're trying to do, the more likely it is we ought to check what external libraries are available
 * 22:51:01 I think I could have gotten my implementation for the Structured logging RFC merged already if I had just written my own logging library, but I'd rather not.
 * 22:52:13  we can discuss individual proposals on their merits, of course
 * 22:52:57  but parent5446 is asking for general thoughts, and so this is my position, pretty much at the other end of the spectrum as far as opinions on reuse go
 * 22:53:40 parent5446: the individual proposals I presume are most congruent with the "replace complicated things" principle would be around config and maintenance/console. What's your assessment?
 * 22:54:03  I have read a lot of code, and most of it was worse than what we have in the MW core
 * 22:54:07  and subject to less review
 * 22:54:20 ^ the review this is important for fundraising
 * 22:54:21 (other principles that are probably pretty obvious: the replacements should be high quality code, friendly & responsive upstreams, etc. HHVM would be an example?)
 * 22:54:46 Yeah I haven't really looked at code, so I can't make a statement on specific libraries
 * 22:54:59 (not a replacement really, but us choosing to work with an existing project instead of going it alone)
 * 22:56:08 #link https://www.mediawiki.org/wiki/Upstream_projects
 * 22:56:11 part of the issue with the way we do things now is that, while being potentially superior along many vectors (performance, reliabilitiy, security), we seem to fall down on reusability, which is unfortunate
 * 22:56:49 The larger PHP community has made great strides in code quality in the last 4-5 years. There is still a lot of nasty stuff out there, but in the PHP 5.4+ library space there are a lot of high quality components.
 * 22:57:11 I got to head out. Sorry for leaving a bit early on my own RFC.
 * 22:57:25 It's ok parent5446
 * 22:57:31 * sumanah decides to sum up
 * 22:57:36 #info this seems like something that�ll be easier to treat once we have a consistent dependency manager :D
 * 22:57:51 i also agree with bd808, while there is alot of crap php out there, there is also a ton of clean, modular code with minimal or no dependencies
 * 22:58:02 and that has all happened in only the last couple years
 * 22:58:10 +1
 * 22:58:33 monolog being good example
 * 22:58:41 #info we feel mixed about the general concept of choosing to reuse external stuff instead of writing it ourselves - depends on code quality, which you gotta take on a case-by-case basis
 * 22:59:00 #info part of the issue with the way we do things now is that, while being potentially superior along many vectors (performance, reliabilitiy, security), we seem to fall down on reusability, which is unfortunate
 * 22:59:42 Most of the Symphony2 code I've read is solid. There's some "javification" in parts but in general that happens when you build flexible libraries.
 * 22:59:52 #info also, we're more likely to be interested in a replacement if the feature is quite complicated, e.g., JS minification
 * 23:00:16 #info examples of good PHP code out there that's reusable: monolog, Symfony2 stuff
 * 23:00:47 All right, I think that's about it today - next week we have no IRC meeting, because of the Zurich hackathon
 * 23:01:00 yay, hackathon!
 * 23:01:00 where we'll talk about performance guidelines and, I hope, thumbnails
 * 23:01:09 Thank you all
 * 23:01:19 woo!
 * 23:01:22 I really appreciate your consistent thoughtfulness
 * 23:01:25 #endmeeting
 * Sharihareswara (WMF) (talk) 23:49, 29 April 2014 (UTC)