Allow to inject an http client

[donquixote]

Currently the BigBlueButton::sendRequest() is hard-coded to use curl_*() methods.

We are working on an integration in Drupal, where we would like to use the (Guzzle) http client service from the DI container.
This is currently difficult, because the relevant methods in BigBlueButton are private. So to solve this with inheritance, we have to replace a bunch of methods that call the private methods.

Proposed change

A good solution would be to split out a part of the BigBlueButton class, most importantly the sendRequest() method, and then inject that new object into the BigBlueButton class.
We can keep the default implementation with curl_*(), and provide an alternative implementation with a PSR-18 http client.

Once we factor out that new object, the signature of ->sendRequest() (or a renamed version of that) will become part of the public API and we can no longer change it.

Alternatively, we could inject an optional PSR-18 client into BigBlueButton, and fall back to curl if no client was provided.

EDIT: If we want to keep all options on the table, we can add a static factory method BigBlueButton::createWithHttpClient(..) which for now would create a new instance with a http client property. Later if we refactor by splitting out sendRequest() into a separate class, we can leave the signature of that static method unchanged.

Challenges, obstacles

I noticed that the ->sendRequest() method changes object variables by calling $this->setJSessionId(), which results in the object not being stateless anymore . I don't really know what we need this for. We should avoid statefulness, or handle it in a smart way, if we want this to be usable as a service

Next steps

I am going to work on a PR, but I also want to open this issue to collect some thoughts from maintainers.

[GhaziTriki]

Hello @donquixote,

I think you are talking about HTTP transport. It would be an excellent addition to make it configurable and PSR-18 compliant.

[GhaziTriki]

@donquixote

Porting our refined e-mail conversation to this comment below:

Injecting a PSR-18 HTTP client would be a great improvement for integration into modern frameworks like Drupal. I agree that separating the transport logic—especially sendRequest()—into its own class is the right path.

We could support both a default curl_*() transport and allow PSR-18 clients (e.g., Guzzle as you suggested in our email exchange) via a method like withHttpClient() or a static factory (createWithHttpClient()), keeping future refactors flexible.

I also suggest considering a lightweight discovery-based approach (e.g. psr-discovery/http-client-implementations) to avoid hard dependencies.

The discussion is open 😄 with no decision voted yet.

[donquixote]

I suspect that the splitting the transport logic won't be that useful in the end, if we mostly just wrap the client and request factory.
As for curl, the main motivation here is to keep the original code for BC. We can drop it in a later version. There are already clients out there that use curl internally.

I will produce a first version that can be a starting point for further discussion.

[donquixote]

Something else I notice is that the constructor has a parameter $opts, but all we use from that is $opts['curl'].
When creating an instance with a client, the options will be already set in the client, and we don't need the $opts parameter.

[donquixote]

Also interesting: The $opts is nullable, but the default is just empty array [].

[donquixote]

I created this preview PR:

• Issue #267: Inject PSR http client into BigBlueButton class, instead of using curl #273

I also looked if we can split up the BigBlueButton class while preserving BC.
All the old properties are only needed in the curl version of sendRequest().

We could keep the existing BigBlueButton class, but have a new class BigBlueButtonWithClient which loses all the unnecessary properties and also all the deprecated methods and any methods that are not needed when using a http client. We could have a base class BigBlueButtonBase which would have all shared functionality, no constructor, no properties, and abstract methods getUrlBuilder() and sendRequest().

We could also split the sendRequest() to a separate class, to be injected.

In the new class we can drop constructor parameters $baseUrl and $secret, and instead have a parameter for UrlBuilder.
The base class would just have abstract protected function getUrlBuilder(), so that each implementation can have its own property, so in one case the $this->urlBuilder can be readonly.

[donquixote]

One thing I would like to avoid is that we create new classes and interfaces that will be considered public, but that we later have to redesign.