On 15 June 2010 11:00, Merlin Morgenstern <merlin_x@xxxxxxxxxxx> wrote: > HI there, > > I am thinking about building a partner network where partners can export > content to my server which will then be imported. It should be as easy as > possible for the partner and not rely on any special php functions. > > > The best way to do this I guess is to deliver them a php file which will > create a xml structure that I can import. The problem I have now is, how to > transfer this xml-file to my server? Of course I could do this via FTP, but > then they need to have FTP enabled inside their php installation. This might > scare some partners away. > > Does anybody have a good suggestion on how to do this? > > Thank you for any hint, > > Merlin > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > We have just done something similar. We went down the SOAP route as this allows third parties to be able to take our WSDL file (which describes the services we offer) and create their own code from it, essentially wrapping the SOAP comms in a class of language x. I used a slightly modified wsdl2php class from sourceforge to create my client classes for our own service, rather than manually creating them, as a proof of concept. So wsdl2java, wsdl2net (if such things exist) would do a similar job. For us, the biggest advantage of SOAP over say REST was that SOAP is a documented standard (with all its faults). We can supply a single document which is man and machine readable and fully describes our service. Admittedly, we used the Zend SOAP, WSDL and AutoDiscovery classes for all of this, so really, we did VERY little in terms of creating the SOAPy bits. We have an Authentication service and then a series of services which retrieve and supply data. We incorporated version control into all the classes. So, V1 is where we are today. As we increase functionality, we can incorporate a "superseded by" mechanism, which the end-user can take into account if they so wish. The WSDL file will have the latest info, they can re-generate their classes from the WSDL file and then take advantage of the new functionality. If we find a problem which essentially breaks the contract, we can kill a version. And if if has a superseded by, we are again, automatically informing the client of the newer code. Add to that live (default), test (we think this is what you asked for) and dev (this is where we are at the moment if you really want to see something) requests for a particular version. As dev becomes test, the dev is "killed" and "superseded by" the test and then the same for the test -> live (with test's not being killed). So. A simple enough setup, but allows us to move at our own pace in terms of further development, allows us to incorporate requests and bespoke requests to meet the needs of our partners ... all good. And it was good fun doing this. Admittedly, there were a few bugs in the Zend code I had to fix (all patches have been supplied but awaiting someone to commit them to the code). Richard. -- ----- Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
