Krinkle added a comment.
In T110022#4508947, @Legoktm wrote:
In T110022#4502131, @Krinkle wrote:
I think this can also work backwards, like if upstream doesn't add support for newer PHP versions, then we're stuck.
I agree that's a general concern to be aware of when comparing vendors.
Legoktm added a comment.
In T110022#4502131, @Krinkle wrote:
This means we can be reasonably certain that we can always use the latest stable version of the library, with upstream support for any issues that may arise in either its public interface or compatibility with any of the PHP versions
Krinkle added a comment.
I agree that non-static state and active maintenance are desirable traits. I haven't recently checked either library for those aspects, but I trust @BPirkle and @Tgr that Guzzle is better in that regard.
I'd like to instead provide feedback on another aspect: Stability.
Krinkle added a comment.
In T110022#4479395, @Tgr wrote:
In T110022#4478166, @Krinkle wrote:
We'd basically map the exception class to a localisation message somewhere [..]
[..]
Mapping by class is not really useful. Mapping by message would involve regex parsing messages - possible but a bit
BPirkle added a comment.
I’m also a soft lean to Guzzle. It seems more active recently than most of the alternatives, suitable to our needs, and generally popular. I hate to overweigh “popularity” as a metric, but in the case of open source, momentum doesn’t hurt. It is also much easier to
Tgr added a comment.
In T110022#4486858, @BPirkle wrote:
Localization questions aside, it seemed that in 2016 (on T139169), @Krinkle preferred Requests, while @Tgr preferred Guzzle. Do each of you still feel the same
Oops, I forgot to follow up there, did it now (god bless Phabricator drafts).
Imarlier added a comment.
FWIW, I'd maybe offer a soft poke in the direction of Guzzle, mostly because I find that having REST-y functionality integrated can be helpful. But it's not something that I feel strongly about.TASK DETAILhttps://phabricator.wikimedia.org/T110022EMAIL
BPirkle added a comment.
Localization questions aside, it seemed that in 2016 (on T139169), @Krinkle preferred Requests, while @Tgr preferred Guzzle. Do each of you still feel the same, and are there any additional possibilities that you've become aware of since then?TASK
BPirkle added a comment.
I wish we could map by exception class, but it seems challenging to do that in a useful way. Looking at the two libraries that have been mentioned:
Guzzle tends to throw generic exception classes. The most popular appear to be:
InvalidArgumentException (49
Tgr added a comment.
In T110022#4478166, @Krinkle wrote:
We'd basically map the exception class to a localisation message somewhere, quite similar to what we already do for various exception types in various places. Perhaps we could centralise that a bit within MediaWiki :)
The fundamental
Krinkle added a comment.
A wrapper would be straight-forward indeed, but another idea to consider could be to handle localisation at a higher layer that catches the exception, and responsible for printing it in some way. That approach might be easier to scale to other libraries we use, including
BPirkle added a comment.
If we do care about localization, there's also the possibility of wrapping an external library in custom code that does support localization. Current http-* entries in en.json are fairly generic and could continue to be so. The external library would handle the details
Tgr added a comment.
Usually the main limitation of external libraries is that they don't support localization (of error messages, mainly). Not sure if we actually care about that in the case of not particularly user-facing libraries, or just took advantage of it because it was free...TASK
Addshore added a comment.
In T110022#4095918, @Dereckson wrote:
@Addshore The https://github.com/addwiki/mediawiki-api-base/issues/5 link has expired
Removed from the description.
The tasks were moved to phab, but I cant remember which one #5 was...TASK
Dereckson added a comment.
@Addshore The https://github.com/addwiki/mediawiki-api-base/issues/5 link has expiredTASK DETAILhttps://phabricator.wikimedia.org/T110022EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: DerecksonCc: Dereckson, Ladsgroup, Krinkle,
Krinkle added a comment.
Per https://gerrit.wikimedia.org/r/#/c/356121/, a good starting point would be to move the (new) HttpAcceptNegotiator and HttpAcceptParser classes to a Packagist-published PHP library.
We can later consider moving other classes to it as well (such as Http::request,
Tgr added a comment.
I poked at librarizing includes/http recently - the dependencies are CookieJar, Status[Value] and at-ease. So StatusValue would have to be librarized first. Also the current interface is rather ugly.TASK DETAILhttps://phabricator.wikimedia.org/T110022EMAIL
17 matches
Mail list logo
