So again... now what. I currently have everything hosted on SourceForge.
Including the website, cvs and all the stuff SF offers you.
Ok, so first, does it go in PECL or in PHP main distribution. I would say PECL for now, then mirror to the main distribution when a "stable" release is done and documented.
I would agree here... but... Has anyone thought about how confusing it might
be to move things to and from PECL/main to end users? Im not exactly up to par
on the PECL stuff. Or where its going.
My understanding of PEAR/PECL:
PECL is part of PEAR, for C extensions (doesn't make any dependencies on pear code). The pear installer will know how to download and build PECL extensions. Some PECL extensions will end up being mirrored, or branched, via CVS controls into the main distribution. That mirroring will happen at times when the PECL extension is at a 'stable' release, so the PHP distribution will always have a stable release of an extension. Meanwhile, between php releases, the PECL extension can do another 'stable' release independently of PHP. When the next release of PHP occures, the latest 'stable' release of core PECL extensions will be included. It's a very sweet system once it gets finished, which should be relatively soon. This is also very similar to the way CPAN works, and how we run PPM (Programmers package manager, which is for Perl and Python).
The next part is to get people on board with the change. Currently xpat is bundled. What will change by bundling libxml? Do we replace xpat? How does that effect other modules (xmlrpc, domxml, xslt, etc.)? Xmlrpc, since that depends on xpat and *will* be bundled starting with php 4.3. We need to talk with Stig about this if libxml is to be an xpat replacement. For now, it might be easier not to bundle libxml just to get started with putting soap into the php cvs.
xmlrpc is being bundled? hmm.. thats too bad. I was hoping that phpsoap could
have a xmlrpc encoding/transport layer incorperated with it. Oh well.
Yes, and Stig is very big with xmlrpc-epi. However, if xmlrpc-epi can use libxml, or be easily modified to do so, and libxml is indeed faster than xpat, perhaps we can make a convincing argument to drop xpat.
I definitly want to be involved at *least* with the design of the for the transport layer.
Sounds good... Maybe you can give me a brief run down how the transport works
before I start looking at your code. Then after i look at your stuff i can give
you feedback on my ideas. Then we can decide where to go.
It's quite simple. A small wrapper class (SOAP/Transport.php) is used by the soap client class. The uri passed to it is parsed, and based on the scheme of the uri, the real transport class is loaded (SOAP/Transport/HTTP.php for example). The transport classes essentialy have a send function and a few supporting functions, that is it.
The issue is more about how the script passes parameters necessary for the transports. It needs to be done in a way generic enough that an arbitrary transport can be added without needing to change the soap client api (SOAPObject in your library). The way I accomplished this is to have one parameter be an associative array. I can then add any parameters that may be needed. So for example, below is a client sending soap via smtp. The 'host' is the smtp server to connect to. 'port' could also be passed. Additional headers can be passed by doing 'headers'=>array(...).
include("SOAP/Client.php");
$soapclient = new SOAP_Client("
mailto:user@domain.com");
$options = array('namespace'=>'
http://soapinterop.org/','from'=>'user@domain.com','host'=>'localhost');
$return = $soapclient->call("echoStringArray",array('inputStringArray' => array('good','bad','ugly')), $options);
// the result contains the messageid of the email that was sent,
// or a fault on failure
print_r($return);
I can start right away with the interop tests, probably get something out by next week. This will tell us where the library stands with interop against other soap implmentations.
Cool.... If you want to wait for 2 or so days I want to get some stuff in
there before you start on the interop tests... I have some stuff that is
commited and isn't commited that i would like to get into a release.
No problem. The time have have to work on stuff is generaly late at night after work, or during the weekend. I have plenty to do ;)
What is the status of literal encoding and document support in the library right now? I spent my weekend examining that stuff and found it
Here is my understanding... rpc is using native data structs and doc/lit is different becuase it doesn't
pass the data in a lang struct it returns more like a xml document used for
data processing?
You can pass native data structures in doc/lit just fine. One of the big things that helped me understand doc/lit was the realization (I knew it, but didn't REALIZE it ;) that you have to seperate the document style (rpc or document) from the encoding (literal or encoded). So you get four combinations:
rpc/encoded
rpc/literal
doc/encoded
doc/literal
Further, each method in the wsdl can define it's encoding style, so you can have mixed encoded/literal in a soap message as defined in wsdl:message/wsdl:part. Different bindings may choose to use rpc or document style, but that effects the entire soap message (as far as I can tell).
So the easiest thing to get right first is the encoding. encoded = typed, literal = untyped. For literal encoding, you do not set any attributes related to encoding (xsi:type, wsdl:arrayType, etc.). Essentialy, you do not have to do any of the Section 5 encoding rules. Makes life a bit easier when serializing/deserializing data, but it's not terribly different.
Document is a little trickier, and I'm still working out some of the details in my head. A document style message MAY OR MAY NOT have a rpc-like call in the body. That is where things get a little fuzy in the documentation, and when I get some more time I will figure that out in full. Document style is preferable if you want to pass 'arbitrary' xml data.
How the soap implementation handles return data is up to the implementation. You can parse it into DOM, leave it as an xml string, or attempt to parse it into native data types. I think the result should be an option set by the script, probably with DOM as the default.
ps.
Are you saving this email chain... It would be nice to have this up on some
email board.
Lets move the rest of this onto the soap list.
Shane