RE: [SOAP] Agenda

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: > > Hi everyone, > I'm here also, of course ;) > > I want to start off a discussion to generate an Agenda for soap > development in PHP. Part of this is to get everyone on board with > working towards the same end goal, part is to generate a requirements > doc to define what SOAP support in PHP should consist of. I'm glad to > see some lurkers here who work on projects like Horde, etc., input on > needs and usage from people working on systems like that would be very > useful. > > I'll start off with my idea's, then everyone can chop it all up :) > > 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 : - different quality level or feature list between both implementations. - 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. - this adds complexity to the conception of the API which will slow down the development of the project. > > This also includes documentation, tutorials, whatever, on top of the > actual library itself. Requests for help, etc. should be on another > list, presumably on of the existing php lists. > > Right now, my assumption is that Brad's ext/soap and PEAR::SOAP will be > used for the baseline of development, but that is not written in stone. > > Design Goals: > A common, well defined API between C and script implementations > C and script implementations should be able to interchange various parts. > Transparency of usage > Interoperability > Expandability 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 > > To define the above a bit further: > > Using the same API and class names between the C and script > implementations allow for something like this: > > if (!class_exists('SOAPServer')) { > include_once('SOAP/Server.php'); > class SOAPServer extends SOAP_Server { > function SOAPServer() { > $parent::__constructor(); > } > } > } > > A script wanting to use the SOAPServer class would always include the > above script. This way the script is always garaunteed to have SOAP > available either through the C library or the PEAR library, or even any > other library that implements the same API. > > We should look at the existing PEAR::SOAP and NuSOAP, which are derived > from Deitrichs earlier SOAPx4, Brad's ext/soap and then some other > languages like SOAP::Lite, etc. to see what capabilities exist and how > they've been implemented. > > There is also a well defined client side api we started developing here > at ActiveState with several SOAP implementors, that could be looked at > for some idea's: http://aspn.activestate.com/ASPN/WebServices/SWSAPI.Ÿ > Jp¸²â°gœÿ¿eêŠ > I'm not pushing to use that API specificly, I feel there are certain > issues with it that would make it difficult to use in PHP and other > items that may not realy be effective for performance reasons, but a lot > of good thought did go into it. Also, in defining the common API for > PHP, I don't think we need to go as far as SWSAPI did. > > Being able to 'exchange parts' is crucial to rapid development or > experimental development at the script level. For example, someone > wants to implement the Jabber transport for SOAP. Being able to > override the C extensions transport layer with PHP script enables a > developer to quickly hash out issues in script, then decide whether to > implement the transport at the C level or leave it in script. There are > other parts that should be factored into classes, for example the soap > message parser, and the serializer. Being able to use these seperately > allows for a complete override of the soap client and server > implementations that are made available by default. in this spirit, this would be really great to have the ability to overload classes and setup handlers for the different core features of the extension, like : - exceptions - serializers / deserializers - transport protocol (adding HTTP Authentication, HTTP Proxy, SSL, ..., use of asynchronous protocols, such as SMTP/POP3 or any custom one) - debugging features (have access to the Headers and Bodies of the Soap Requests and the Soap Responses) > > Transparency of usage implies that no knowlege of SOAP is necessary for > a user to use and implement SOAP services. I would say that this is true for a basic use of Soap, but for "advanced users" it sould still be possible to have access to more features, with maybe less transparency :) > The current level of > transparency requires a few lines of code to implement the server on top > of a class the developer writes. It also requires good usage of WSDL to > (de)serialization. PHP currently has some built-in XML serialization > through a module, that uses some common serialization code in PHP. > Hooking into that type of a model may provide some very interesting > benefits. We could also consider taking this a step further, and give > PHP the ability to handle SOAP requests the same way it handles POST > data, but that's just a random thought. > > Interoperability is critical. There are lots of interop issues. It's > something I have focused the bulk of my time towards when working on > PEAR::SOAP. There is a body of SOAP developers that work on interop > issues, called SOAPBuilders, both Deitrich and myself are on that list > and involved in interop tests. Using a consistent API will allow us to > leverage a single interop test suite to both the C and script > level systems. > > Expandability allows us to easily add new features without needing > changes in the API. This needs to be considered while generating the API. > > > Shane > > > > -- > PHP Soap Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif