Re: [SOAP] Agenda

phpsurf wrote:

Hi, I hope to contribute on this list as a very impatient PHP Soap user ! I have also big working on serveral projects using soap in java and have already been experimenting a few php implementations. about that, I really must say that brad's extension really is the most use-friendly one, and I'm glad to see that it will be used as a basement for this project. as you suggested, I added a few comments to your agenda proposition:

Cool! I was beginning to feel like I was talking into a void ;)

Primary purpose of this list: Development of a base SOAP implementation that will be part of the default PHP distribution. This includes a C extension and a PEAR library, which would basicly replace and/or enhance what I've done in PEAR already. The reason for the dual development is to have a script based implementation that would be automaticly used if the C extension is not loaded.

I understand this need for a script implementation, but if the C implementation is aimed to become part of PHP core is it still useful ? The main problem I see in this dual implementation of the same thing, is that you'll have to maintain two projects instead of one and this can lead to :

Well, I'm not realy worried about maintenance of two systems, and I don't consider it two projects, rather one project with developers working on different aspects of it. There are two major reasons for a dual implementation. One is for systems that don't have the C library installed. This was an issue with the pear installer itself, since it used xmlrpc, but often xmlrpc-epi is not installed. Now the script implementation of xmlrpc is used in that situation, which allows the pear installer to work on any configuration of php, even if the script implementation is significantly slower. The second is for experimental development of new soap capabilities. There is a lot more to soap than serialization and send/recieve. DIME, UDDI, SwA, Authentication, etc. etc. With a dual system where you can override parts of the C library in script, these new capabilities can be developed quickly in PHP, then eventualy and likely more accurately developed into the C library itself. Also, if someone using soap needs a new transport protocol, they could simply write it in PHP rather than digging into C code they may not be familier with. The second situation is the hot button for me. I'm a long time c/c++ developer, and actually use them more than php script. However, I find it much faster to figure out a problem in script than in C. Once the problem is figured out, porting to C is often trivial.

- different quality level or feature list between both implementations.

Not realy an issue. The idea is that the C library is extendable via script, and replacable by script IF the C library is not available.

- the need to wait to publish a new release for one implementation to have

its new features also implemented in the other one, in order to avoid desynchronization, this slowing down the releases.

As long as a well defined API is in place, there should be no issue at all with different release cycles.

- this adds complexity to the conception of the API which will slow down the

development of the project.

We already have at least 2 API's, and they are fairly simular already. It's a matter of looking at them, see what they are doing and why, and merging them into one API that both will implement.

I would like to add one point to this list which I think is really important, but not specific to the SOAP extension : - Compatibility with Zend Engine 2 As the development of the SOAP extension will take some time, we can already be sure that when it comes out, Zend Engine 2 will have already be bound to the main PHP distribution. Then we sould ensure that we will make a good use of the new features introduced by Zend Engine 2. I especially think about : - Exception handling

I probably won't take that long since there are already implementations in existence, and it's realy just a matter of making them interact in a compatible way. Whether ZE2 will beat it out is certainly possible, but questionable. And yes, exception handling is one of the BIG things I realy want :) Shane