Jump to content

Talk:Requests for comment/Third-party components

Add topic
From mediawiki.org
Latest comment: 10 years ago by Sharihareswara (WMF) in topic Discuss next week?

Logging / Monolog

[edit]

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)Reply

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)Reply
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)Reply

Where it makes sense

[edit]

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)Reply

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)Reply
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)Reply

Why Swift Mailer?

[edit]

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

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)Reply
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)Reply
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)Reply

CLDR

[edit]

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)Reply

Discuss next week?

[edit]

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)Reply

Afternoon in what timezone? Better give UTC hour ranges... --Nemo 15:23, 23 April 2014 (UTC)Reply
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)Reply
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)Reply
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)Reply