Find async or non-async client

[sagikazarmark]

In some cases it doesn't matter if the installed client is sync or async (for example when known to be used in PluginClient). For that we could have a discovery which finds a sync or async client.

[dbu]

or the code could just try to discover whatever it prefers, catch the exception if none found and try the other. i would not overdo it with factories ;-)

[sagikazarmark]

Actually, I was thinking about the same 😄

But it would still be useful as a snippet somewhere.

[dbu]

sure, mentioning it in the doc would make a lot of sense. maybe a section in the client discovery doc?

[joelwurtz]

Or we could add an argument to the find method where we allow emulated client

HttpAsyncClientDiscovery::find($allowEmulation = false);

So if no async client is found and allowEmulation is set to true it use the SyncClient Discovery and encapsulate it with an emulated async client.

WDYT ?

[Nyholm]

The only time you use HttpAsyncClientDiscovery::find() is when you are a library author. If you are a application author and writing your own code then you probably do not use discovery at all.

As a library author you usually do not care if the client is emulated or not, you just want the async client api.

The only time you care is if you are an application author using a library that is using HttpAsyncClientDiscovery::find(). Then you want to make sure discovery will find an async client. With that said, we cant have any special parameters to find() nor can you have a special HttpAsyncClientDiscovery::findNoEmulated().

What I propose is that we, by default, are trying to find all real async clients and then fallback on emulated ones.

[sagikazarmark]

I would rather keep it simple and let the developer handle the situation. We don't know the preference of a given code. Adding emulation related code to the discovery adds an extra dependency (client-common) and complexity.

[dbu]

i agree that we should keep discovery simple. you can try to find async, if not found find sync and wrap it, if that is what you need. finding a sync client and hiding that by wrapping it in an emulator is doing a disservice, and adding tons of configuration options is complicating things too much imho. if somebody really wants to use discovery and the emulated client (e.g. using a library that only finds an async client and has no DI, but you need to use it with a sync client), they can still explicitly set the emulated client on the async discovery. so the current code does cover all conceivable situations, but makes emulation a bit more effort for the sake of transparency and simplicity

[Nyholm]

Okey. Big -1 for adding more dependency.

The situation we have not covered is when I as a library developer what to emulate a async client. I believe I can write an extra strategy for that that we let the users opt-in to.

[Nyholm]

I just added #65. I as a application author may write a strategy like that. What I want to push in is the support for a strategy to return a candidate with a closure.

What do you think? That would make the discovery super flexible, but... could it be too flexible?

[dbu]

do we still need to do something about this or is it good enough as is?

[sagikazarmark]

We agreed to add a cookbook entry

[dbu]

php-http/documentation#117