[draft] Issue #267: Http client - first preview

[donquixote]

See

• Allow to inject an http client #267

This probably won't work. Just a preview prototype to see the general idea.

I would like to split the class, so that the version with a http client does not have methods like ->setTimeOut() that have no effect. We could use a shared base class for that.

[donquixote]

For cookies, see:

• Support: Clarify what we do with cookies #271

@GhaziTriki Let me know if we should follow up in the direction of this PR, or do things differently. Obviously this cannot be merged as-is.

[GhaziTriki]

@donquixote looks good so far. Let's continue this pathway, and everything should be clear with an example once the implementation is finished. We need a default transport or auto-discovery when not explicitly set.

[donquixote]

I think this would be "an http client"..

Suggested change

	* This has no effect if the instance has a http client.
	* This has no effect if the instance has an http client.

and same for other similar places.

[donquixote]

Should we have the UrlBuilder injected instead of passing base url and secret?

[donquixote]

We need a default transport or auto-discovery when not explicitly set.

Not sure what you mean by this. The fallback to env vars as in the constructor?
I would rather avoid this.

The main purpose of this package (I think) is to be pulled in as a dependency to be used by other code.
It is usually the application that is responsible for managing secrets. I don't know if every application wants to use the same env var mechanism that this package supports.

[donquixote]

@GhaziTriki I think eventually we want to be able to inject the UrlBuilder.
People will need their own instance of it to call the methods.

I think it is better to discuss this separately, see

• Inject UrlBuilder instance into the BigBlueButton constructor #286.

[donquixote]

This is a cheap way to run the same tests with curl and with a http client.

In the future we may come up with something better, perhaps.