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)

Gerrit change 112699 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 bugzilla: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)

** <brion> 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)

** <robla> 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 <sumanah> #topic MediaWiki libraries

22:43:16 <sumanah> #topic Third-party components

22:43:20 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components

22:43:26 <sumanah> #info Tyler Romeo's proposal (replacing some MW components with more widely used libraries, especially Symfony libraries)

22:43:39 <aude> it would be cumbersome to manually register all the dependencies of wikibase

22:43:41 <sumanah> #info parent5446 is looking for feedback on the general concept.

22:43:46 <bd808> which requires a package manager :)

22:44:17 <sumanah> 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 <parent5446> Hence the advantage of discussing these two RFCs together

22:44:24 <aude> bd808: yep

22:44:41 <sumanah> 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 <brion> *nod*

22:45:01 <TimStarling> I don't think I am in favour of this general direction

22:45:02 <brion> this seems like something that’ll be easier to treat once we have a consistent dependency manager :D

22:45:06 <brion> hmm

22:45:26 <Dantman> I like the idea of using a full mail library. But I don't like the replacement of WebRequest.

22:45:29 <TimStarling> when we maintain our own small libraries, we can make changes to them

22:45:42 <TimStarling> the more we use external libraries, the more we will be blocked waiting for upstream

22:46:04 <TimStarling> with our own code, we maintain some flexibility

22:46:26 <TimStarling> for complicated things like JS minification, sure, use an external library

22:46:26 <brion> we can maintain local patches but that way lies madness

22:46:35 <TimStarling> but I don't think it makes sense for simple things like curl wrappers

22:46:42 <andrewbogott> How are those other (external) libs hosted? Would managing them drastically increase the scope of what composer has to do?

22:46:48 <mwalker> 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 <robla> isn't this chain of logic the way to wheel reinvention hell?

22:47:31 <parent5446> I wouldn't use the extreme as the norm

22:47:41 <brion> wheel not reinvented here :)

22:47:41 <parent5446> Not all libraries are dependency hell or hard to get things fixed upstream

22:47:57 <sumanah> 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 <TimStarling> I don't really believe in that phrase

22:48:18 <TimStarling> I think there's a difference between making a wheel and inventing a wheel

22:48:38 <TimStarling> having studied many wheels, a good engineer can make a wheel for a specific purpose without much difficulty

22:48:40 <parent5446> Making a custom mail library when SwiftMailer already exists in re-inventing the wheel

22:48:50 <TimStarling> the same is true of libraries

22:49:04 <andrewbogott> 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 <bd808> 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 <TimStarling> "don't reinvent the wheel", taken literally, encourages study, not recycling

22:50:00 <sumanah> 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 <mwalker> do we have anyone here who has maintained jQuery in core? I feel it is a good case study

22:50:47 <sumanah> 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 <bd808> 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 <TimStarling> we can discuss individual proposals on their merits, of course

22:52:57 <TimStarling> 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 <sumanah> 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 <TimStarling> I have read a lot of code, and most of it was worse than what we have in the MW core

22:54:07 <TimStarling> and subject to less review

22:54:20 <mwalker> ^ the review this is important for fundraising

22:54:21 <sumanah> (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 <parent5446> Yeah I haven't really looked at code, so I can't make a statement on specific libraries

22:54:59 <sumanah> (not a replacement really, but us choosing to work with an existing project instead of going it alone)

22:56:08 <sumanah> #link https://www.mediawiki.org/wiki/Upstream_projects

22:56:11 <robla> 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 <bd808> 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 <parent5446> I got to head out. Sorry for leaving a bit early on my own RFC.

22:57:25 <sumanah> It's ok parent5446

22:57:31 * sumanah decides to sum up

22:57:36 <sumanah> #info <brion> this seems like something that�ll be easier to treat once we have a consistent dependency manager :D

22:57:51 <ebernhardson> 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 <ebernhardson> and that has all happened in only the last couple years

22:58:10 <aude> +1

22:58:33 <aude> monolog being good example

22:58:41 <sumanah> #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 <sumanah> #info <robla> 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 <bd808> 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 <sumanah> #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 <sumanah> #info examples of good PHP code out there that's reusable: monolog, Symfony2 stuff

23:00:47 <sumanah> All right, I think that's about it today - next week we have no IRC meeting, because of the Zurich hackathon

23:01:00 <aude> yay, hackathon!

23:01:00 <sumanah> where we'll talk about performance guidelines and, I hope, thumbnails

23:01:09 <sumanah> Thank you all

23:01:19 <brion> woo!

23:01:22 <sumanah> I really appreciate your consistent thoughtfulness

23:01:25 <sumanah> #endmeeting

Sharihareswara (WMF) (talk) 23:49, 29 April 2014 (UTC)