Use Guzzle 4.x

[and1truong]

Can this library updated to Guzzle 4.x? Thanks.

[bakura10]

Hi,

Is there any reason to do so? I didn't try Guzzle 4 yet, do you think the change would be easy to do?

[and1truong]

Is there any reason to do so?

For new projects, people will select Guzzle 4.x (quite stable for now). But it will conflict with this library.

do you think the change would be easy to do?

I did not check API changed yet. But I think it would not be hard.

[bakura10]

AWS is planning to do so for its SDK. I'm going to evaluate this today. I have severe libraries I need to update. I may try on this one.

It won't conflict because Guzzle 3 and Guzzle 4 are in different namespaces, so you can use both projects interchangeably. However, the simple fact that Guzzle 4 is 30% faster makes it a valid reason to update everything.

[and1truong]

👍

[bakura10]

Hi again,

I'm facing several problems currently with Guzzle 4, especially related to exceptions :). I've raised a few issues to the Guzzle 4 developer. Hopefully ZfrMailChimp will be released later tonight or tomorrow with Guzzle 4 support!

[bakura10]

Hi again @andytruong ,

I've reverted the work on Guzzle 4 for now. This bug is blocking to me: guzzle/command#14

Furthermore the fact that Commands and Services part of Guzzle 4 are still in early development according to Jeremy leads to the fact that I'll likely wait a bit more (maybe one or two months) before migrating modules to Guzzle 4. I prefer to wait a bit so that everything stabilizes :).

[indeyets]

guzzle is 5.x already. and it is awesome!

[bakura10]

I've started migrating ZfrStripe to Guzzle 5 (zf-fr/zfr-stripe#14), but there are still a few things I'm having a hard time to replicate (handling exceptions error).

[bakura10]

Hi everyone,

I don't have the time right now to do the migration for ZfrMailChimp (it's pretty big!). However, I'm nearly done with ZfrStripe, and if someone want to take some hours to follow what I did for ZfrMailChimp, this would be HIGHLY appreciated.

There are a few things to do:

• For consistency, we need to rename the descriptor, from using "GetSomething" to "getSomething" (example: https://github.com/zf-fr/zfr-stripe/pull/14/files#diff-ed325a37c609c635eb187eee8575a565R67). This maps better with how it works in PHP userland.
• Some changes have to be done in the client. It does not extend Client now, but instead composes a GuzzleClient (https://github.com/zf-fr/zfr-stripe/blob/guzzle-5/src/Client/StripeClient.php). There are also a few changes to do with listeners.
• Guzzle 4/5 removed ResourceIterator, so we are now forced to replace it with a user-land iterator class. An example of what I did for ZfrStripe: https://github.com/zf-fr/zfr-stripe/blob/guzzle-5/src/Client/Iterator/StripeCommandsCursorIterator.php

If someone want to tackle this, please let me know!

[trsteel88]

+1

[bakura10]

As guzzle 6 is now here.... I'll also try to actually upgrade to the v3 API of mailchimp :).

[bakura10]

I do not have time to upgrade that unfortunately, but Guzzle Services has been tagged to 1.0.0 so upgrading to Guzzle 6 is now possible.

For those who'd be interested in upgrading this package, I've already upgraded my package ZfrShopify (https://github.com/zf-fr/zfr-shopify) to this new version. It should contain some hint on how to do it.

However there are still some issues like this one (guzzle/guzzle-services#129) that make me think we should wait a bit :).