outdated ringcentral psr pkg

[bitgandtter]

There is any real reason to keep using https://github.com/reactphp/http/blob/master/composer.json#L38 instead of the forked by the same project guzzle pkg which seems to be more updated?

[SimonFrings]

@bitgandtter thank you for the ticket, this has already been discussed in #331, take a look at @clue's answer, he did a good job at explaining the why/why not.

We're only using a small part of RingCentral so the plan is to drop this in a future version. Additionally, we want to build our own implementation that adds some more functionality we can use (async implementations etc.).

[clue]

I believe this has been answered, so I'm closing this for now. Please come back with more details if this problem persists and we can always reopen this 👍

[bitgandtter]

The big issue is that the intention comes from 2018 4 years ago and the package is deprecated. We understand that there is not enough men power to develop a new package from the ground up which is ok but changing it from a well-implemented and maintained package like the guzzle one is just one line of code away. Not doing it put everyone using this project at risk besides other issues like not having features implemented. Maintainers of this project should take action on the matters instead of looking away from the real issue.

That said your point on your message @SimonFrings that @clue explains on #331 the reasons for not changing it but ms @clue limits all his messages to only closing issues so there is no real explanation on why it's not taking action.

As a developer and also a user of your package I encourage you to please take action and help us keep going we really appreciate the work excellent you guys do

[clue]

@bitgandtter As much as I understand your frustration, I still fail to see the "big issue" you're trying to proclaim. This project is well maintained and actively developed and to the best of my knowledge there are no known issues beyond the outstanding feature requests that we keep track of in this issue tracker. You brought up a valid question with this ticket and I feel it is adequately answered with the above reply and the details provided in the linked tickets (see also their linked tickets). If you feel there's anything that needs to be addressed beyond this, please let us know what problem you're seeing and we'll get this sorted out as soon as possible.

We also very much welcome PRs and helping hands! For us, working on the code base is the easy (and fun!) part, but there's far more work involved here. The harsh reality is that I currently have a few hundreds of tickets throughout my projects that all very much deserve an in-depth reply and a thorough answer. I could easily spend half an hour on each ticket or several(!) weeks full-time just writing replies without making any functional progress in any of these projects all while earning not even a single cent in compensation for this. I hope you understand we're all trying our best to balance between these ends and also trying to make ends meet along the way. The good news is that this is where you can step in, help us, and show your support! See the red "❤️ Sponsor" button at the top of each repository.

Assuming you want to support this project and our work, I'll end this wall of text with a warm thank you! If you feel there's anything else that needs to be addressed and is not already covered above, please let us know and we will look into this. Please note that the fact that this ticket is currently closed does not limit our way to keep this discussion ongoing in any way. Cheers!

[bitgandtter]

Thanks for your time and your hard work @clue. The thing is that the issue marked as closed is IMHO not accurate since the issue it's not been solved. The correct course of actions should be on of below:

1. hey we understand but we don't have the men power to address it, please create a PR or sponsor as you advised above
2. hey there is this other issue where we are tracking the same problem, we will close this one because its a duplicate

If there is no open issue that remains the community and the maintainers that there is a big and actual problem then the problem is very likely not going to be solved which is the current scenario.

That said I'm happy to contribute and create a PR that fix it, and that was sort of my goal understand if there is any internal effort to solve it or you need help

[clue]

Thanks for your time and your hard work @clue.

You're welcome, glad you appreciate this!

The thing is that the issue marked as closed is IMHO not accurate since the issue it's not been solved.

I understand you're saying "the issue [has] not been solved", but allow me to be blunt, what issue are you seeing specifically?

This ticket is closed because it brought up a valid question that I believe is answered. I currently fail to see any issue beyond this.

[bitgandtter]

The issue, and yes you are right that I open with a question; is that the ringcentral/psr7 lib is kind of unmaintained and with missing implemented methods vs the guzzle/psr7 which its actually the source of the ringcentral one. The guzzle/psr7 its fully implemented and maintained.

[clue]

I agree that the PSR-7 implementation currently in use could use some love, but other than that I don't currently see much that would be gained by going with a different implementation. As discussed in #331 (and linked tickets), we're only really using a small subset of its functionality and already have to implement some custom async functionality on top of this, hence why we're slowly migrating to providing our own built-in implementation.

All of this is purely an implementation detail, so it will not affect the public API in any way. We take our backwards compatibility promise very seriously and care about long-term support (LTS) and predictable, stable releases. As a consequence, we will try to avoid BC breaks whenever possible.

You've mentioned seeing some "real issues" and "missing […] methods" which I'd still be interested to learn about. I also invite you to give it a shot and file a PR. In either case, make sure the current test suite passes, add relevant test cases where new functionality is added or any issues would be fixed, and provide reproducible benchmarks (#162) to show performance implications. If it improves the project in any way, I think we're all more than happy to get this in!

[bitgandtter]

You've mentioned seeing some "real issues" and "missing […] methods" which I'd still be interested to learn about.

Just to mention one and for us a big one. The UploadedFile is not implemented which is on the original lib

[clue]

The UploadedFile is not implemented which is on the original lib

Fair enough! We already (have to) implement an internal UploadedFile (#199) which we do not currently expose as part of our public API, so using either RingCentral or Guzzle makes no difference for internal usage.

If your code depends on an UploadedFile implementation, I would recommend adding a dependency on a package that exposes this API. Afaict there's nothing stopping you from using Guzzle or any other PSR-7 implementation for that matter 👍

I'm also not opposed to exposing our own UploadedFile implementation in the future if we deem the API stable enough and worthwhile (similar to #370). Afaict this does not affect which underlying PSR-7 implementation we're using, so this would only partially affect this ticket here.

I'm planning to work on file uploads (see #428, #412, #371, #274, and others) for a future release and will look into this again. In the meantime, adding an external dependency on your PSR-7 implementation of choice seems to be the way to go 👍

[bitgandtter]

It's not that easy as it seems. Yes we are doing it right now with a few workaround but there are lot of code that imho should not be on our side given that there are psr7 implementations that include them. What I don't really get its that the ring central lib it's not been maintained and it's forked from the guzzle which it's maintained and also fully implemented. That's why my initial proposal was to simply replace them. I fail to see the BCB or any other issue

[clue]

I agree, unfortunately it's never as easy as it may seem. For instance, Guzzle does not support the same PHP version range supported by this package at the moment (see #331 and #319), so we would have to update our version range which in turn would be considered a BC break. Note I'm not suggesting keeping old versions forever, but merely stating that we do care about our BC promise, so this requires a concentrated effort for the new major version. There are plans to update our version range in a future version (see #196), at which point we could also go for another PSR-7 implementation 👍