Repository navigation
Why is ext-soap-engine required? #432
Description
| Q | A |
|---|---|
| Version | 2.2.0 |
Support Question
As I understand it, php-soap/ext-soap-engine is a concrete implementation of interfaces and contracts defined in php-soap/engine. So my question is: why does this package require both of them? Doesn't this nullify the point of abstracting out interfaces and contracts in the first place?
Activity
veewee commentedon May 17, 2022
Hello there,
Good question!
This package is an oppinionated implementation of soap presets that have proven to work for us.
Where the
php-soaporganisation is a set of packages that you can use in order to build a SOAP client implementation from scratch.The main reason for including the
ext-soap-engineis that we currently don't have any other working implementation of the engine. Once we have one, we can make the implementation opt-in or choose the best one as a default preset.Adding a PHP based engine instead of using ext-soap is on the roadmap - if we can find time for it some day :)
However : It's not because we include it by default, that you have to use that specific implementation.
rimas-kudelis commentedon May 17, 2022
Wouldn't it make more sense for
ext-soap-engineto"provides"an abstractphp-soap/engine-implementation(or similar) package, and forphpro/soap-clientto require that instead? It would allow for third-party implementations you might not even be aware of.I was actually quite surprised that
soap-clientnow indirectly requiresext-soap. This wasn't the case with 1.7, but you specifically disallow using 1.7 with PHP8.1 now, so, in a way, I'm being forced to choose between a PHP downgrade and an extension.Is the rationale for these choices laid out anywhere? :)
veewee commentedon May 17, 2022
You can read about it more here:
https://github.com/phpro/soap-client/blob/v2.0.0/UPGRADING.md
Basically the codebase of 1.7 got split up into a separate organisation, which is
php-soap.This organisation contains the core building blocks for creating your own SOAP client implementation.
The 1.7 version of this package did have the flexible engine logic and therefore didn't require ext-soap - which is basically a lie. Splitting that repo up into separate repo's made it easier to maintain the dependency graph per what component you want to use.
So in the old version, you might got the false impression that you didnt need ext-soap, but trust me you did need it!
In short : You never had a choice of not having ext-soap in 1.7 either.
Adding a
provideswould indeed make sense for theext-soap-engine. Feel free to do so.As mentioned before, this is a very oppinionated implementation that aims to give you sensible defaults so that you don't receive too many strange erors (of which we have had plenty!).
Therefore we created a DefaultEngineFactory that trusts the ext-soap-engine and the psr-18 implementation to be there.
See:
https://github.com/phpro/soap-client/blob/master/src/Phpro/SoapClient/Soap/DefaultEngineFactory.php
That is why we cannot drop the dependency in this package.
It is possible, but I know how much work it would be to implement this.
I'dd rather co-work out something we can all manage and fine-tune
Life is too short to make too many SOAP engines ;)
rimas-kudelis commentedon May 17, 2022
Hm, thanks for your patient explanations!
Feel free to convert this issue to a discussion – that seems more appropriate.