On 15 June 2010 11:00, Merlin Morgenstern <merli...@fastmail.fm> 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 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

Reply via email to