On the server side I don't want to have to re-create a SOAP server or
have to keep building a tree and serializing it to be able to pass data
between a tree and ext/soap (assuming the processing were broken out
into discreet steps). The client side isn't a big of a deal to me since
there already is access to the serialized request (but if the server
side were changed to allow this it might be good to allow similar on
client side).
For instance, soap server handles processing the headers, then I want
access to request at that point to do some things with it and at which
point I may or may not have a completed response, which I would like to
pass this tree back to the soap server to either finish processing or
send back to the client. In some cases, I want to be able to be able to
access the response just before it is sent back to the client (such as
to perform encryption).
Really it allows for a user to add additional functionality that may not
have or may not be been implemented by the soap extension (or even work
around any issues that may or may not be bugs without having to wait for
a new release or to work with other soap implementations which are not
working as they should be).
Right now I have a real hacked up custom soap extension that I need to
re-build any time I need to add /change functionality that I cant do in
userland with ext/soap. At least this way it makes it easier to be able
to perform most of this in userland rather than hacking the extension.
As far as an example goes, I will illustrate on the client side (server
side is a bit more complicated and would require discussions around how
it were to work and api additions), but hopefully you get the idea of
what the import method does. (Let me know if you were asking more about
the actually implementation of it within the extension).
take the current __doRequest() method. It passes the request string.
Rather than having to have soap serialize the request tree, pass it,
then re-build the tree, it could work like:
__doNEWRequest(args <without serialized request>...) {
$dom = new DOMDocument();
$dom->dom_import_simplexml($this) /* assumes this is executing within
context of extended soap client object */
/* dom is now the in-memory request tree which ext/soap is using so
any modifications are performed on the real request structure */
. . .
}
I was thinking about how to indicate which tree the import should work
on and it could either be based on the current context of the client
(i.e. after it has performed the request, the context would be that of
the response). Or a property to indicate if the user wants to work with
the request or response.
One more note, as I noticed someone was thinking about working on a
patch is that this type of functionality is not to be taken lightly and
needs much thought (my reason for not having brought this up earlier -
plus it has still just been ideas I have been tossing around and nothing
I have been able to look at seriously). On the client side, at a minimal
you are talking about hooking into the functionality in ext/libxml to
handle ref counting and node/document lifetime). On the server side, it
is much more complicated as I mentioned it should be possible to break
the request handling into different steps rather than calling handle()
which performs processing of the header/body and returning response back
to client.
Rob
Dmitry Stogov wrote:
Why do you need ext/soap on server side if you like work with dom?
You can do just
$dom = dom_import_string($HTTP_RAW_POST_DATA);
Dmitry.
--
PHP Soap Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
