-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Demo of soap engine #36
base: main
Are you sure you want to change the base?
Conversation
Hi @veewee This looks promising. Reason I don't want to adopt it as a complete replacement is simply because (and no disrespect) your package has little in the way of traffic. I'd want it to be more battle tested before we adopted it as the default. I'm going to take a deeper look at this soon, so I'll reserve further comment until then. |
Hello @lukeraymonddowning Thanks for your answer. As mentioned earlier. The new php-soap organisation consists of the low-level (and battle tested) code from phpro/soap-client. There is nothing very new in there. We are planning to remove the code from phpro/soap-client for v2 and use the code inside the php-soap organisation (somewhere end Q3 / beginning Q4 hopefully) So don't let the numbers fool you :) |
Just wanted to let you know that we've released stable versions of all packages mentioned above. |
Hey @veewee, thank you for all the work and efforts on this! And as well, thanks for your assistance with the issues 👍 Be keen to hear what @lukeraymonddowning has to say, but I feel this should be a v2 feature if we go for this. And that we would abstract a little to allow for a native SoapClient driver, a driver from your packages or indeed any other driver desired. |
If we can get this to work with minimal effort, I'd gladly tag it as 2.0. I think even if there are no visibly breaking changes, it would still be prudent to make sure people know they're moving away from the native SOAP client. I'll set aside some time to play with it. |
Ok. Let me know if I can be of any assistence. |
@veewee we'd like to add Http support as an additional Is it possible to set up a pairing session with you at some point so we can take a look at integrating together? |
@lukeraymonddowning that sure is possible, I make time for open-source during the day every last friday of the month. So that timeframe would be my best choice. Otherwise I can arrange some time in the evening. I'm in the Europe/Brussels timezone and assume you are located in the UK - so I am 1h ahead of you. |
@veewee sounds good. Any chance you can give me a way to get in touch privately? Feel free to DM me on twitter: https://twitter.com/LukeDowning19 For reference, you can see an example of the kind of direction we're taking for v2 in this PR: #44 |
Hello,
Based on #35, I created a small PR to demo what is possible in this package.
This PR is currently meant as a showcase to see what directions you can take.
I've added lots of comments to give you some additional feedback on what is possible and how you can optionally deal with specific settings.
As you can see, the more settings you add to the request interface, how more flexible the system becomes.
Creating 2 different instances of this interface (as suggested) is possible as well, but introduces some more questions: Which one is default? How can you switch? One implementation can do more than the other one, so how would you bake all of that into one interface? Maybe the most important question : do you really want to support 2 different implementations? Most of the people want an implementation that works.
Feel free to try this PR out for yourself.
The public API remained pretty much untouched.
Example:
Looking forward for some feedback!