[PROPOSAL] Request feedback on replacing ezimuel/ringphp

[jeabakker]

What/Why

What are you proposing?

I've developed an OpenSearch plugin for my project (https://github.com/Elgg/Elgg). While trying to update my plugin I ran into a dependency conflict. My project uses react/promise ~3.1, ezimuel/ringphp uses react/promise ~2.0 thus my dependency conflict. Since ezimuel/ringphp hasn't had an update in +/- 2 years and that was a fork of an abandoned project maybe it's time to replace it.

What users have asked for this feature?

This was already discussed in elasticsearch in 2020 https://github.com/elastic/elasticsearch-php/issues/992 https://github.com/elastic/elasticsearch-php/issues/990

What problems are you trying to solve?

A composer dependency conflict

Are there any security considerations?

Using maintained code is always better than using abandoned code

Are there any breaking changes to the API

Unknown, but is done correctly I don't see how

Are there breaking changes to the User Experience?

shouldn't be

Why should it be built? Any reason not to?

Using maintained code is always better than using abandoned code.

What will it take to execute?

Replace parts where RingPHP is used with new code

[jeabakker]

Elasticsearch dropped RingPHP in 2022 https://github.com/elastic/elasticsearch-php/commit/aeb7aaacdd6a6fc8791a0be91cfc2544c9db346f#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34

[dblock]

Yes, we should replace it. Appreciate a PR!

Please make sure not to look at any non-APLv2-compatible code.

[stof]

The Elasticsearch PHP client uses the MIT license.

[ProCycleDev]

See #219

[ProCycleDev]

I submitted a MR to ezimuel/ringphp to fix this in the meantime while a long term replacement is found. Hopefully the maintainer is still around. https://github.com/ezimuel/ringphp/pull/11

[dblock]

The last release was from 2022 so I am going to say it's unlikely :(

[stof]

Ezimuel is the maintainer of the elasticsearch-php SDK. As that SDK stopped using ringphp in its version 8, I also think this is unlikely.

[kimpepper]

As a library, we should not have a hard dependency on a HTTP client.

Instead we should move to using PSR-17 HTTP Message Interface, PSR-17 HTTP Factories and PSR-18 HTTP Client.

For composer dependencies we can use the virtual packages psr/http-client-implementation and php-http/async-client-implementation

This allows projects to re-use existing HTTP clients that support the PSR standards, and a avoids the issue we have now with unsupported transitive dependencies.

[dblock]

@kimpepper Yes. There's an unfinished PR for this in https://github.com/opensearch-project/opensearch-php/pull/228, but alternate implementations are welcome.

[kimpepper]

I created an initial PR that does that #233