RE: [SOAP] Re: soap stuff

hi i've not been too far through your mail yet, but there's just one thing that raised to me : PLEASE, before designing you API, please have a deep look to brad's extension, and study how simple it is to call methods on a soap object ! you don't have to do such complex calls : > $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); but simply : $soapclient = new SOAP_Client("somewebservice.wsdl"); $return = $soapclient->remoteMethodName($anySerializablePHPVariableDescribedInTheWsdl) ; all the boring staff (namespaces, message structures, ...) which is specific to the called service, is described in the WSDL and doesn't need to be defined in PHP for each call. and the method is transparently called remotely, when its syntax seems to be local. this all really makes life A LOT easier ! I think to have such a behaviour with PEAR (i mean PHP-side, vs C-side) you could maybe use the new overload extension, using especially the method call overloading feature ... hope you agree with an API like this one ! > -----Original Message----- > From: Shane Caraveo [mailto:shane@caraveo.com] > Sent: mardi 28 mai 2002 23:11 > To: brad lafountain; soap@lists.php.net > Subject: [SOAP] Re: soap stuff > > > >>> 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 > > > > -- > 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