Matthew Peters wrote: > If anyone has an application where they would really like such a > thing, but does not mind if progress is a little slow, I'd be glad to > hear from them. Also, if anyone is excited by the idea of taking a > look at it and making it better I'd like to hear from them too!
I had a go with the Atom binding a few days ago, to try to implement a quick solution to a challenge from a colleague - results may appear as an article sometime in the future. I'm sorry to say I gave up after a while and instead provided a solution using CURL and XMLWriter :-( The nature of the problem was to create a new feed entry with specified content, in a particular format, using Atom. So I needed, in my SCA client, to create the xml for the entry, and POST it to the non-SCA server. I do realise that the Atom binding is experimental, and indeed that some of the problems may be my mistakes - here follows a list of the issues I encountered. 1. The examples led me astray Like all lazy programmers, I started out trying to hack the example code. This told me that it was not possible to use SCA:getService() with Atom services. For example, ContactFeedConsumer starts out: /** * A component which consumes a contact atom feed service. This is * currently required because of the lack of support for * SCA::getService() for atom services. and continues: /** * A reference to the contact feed service. The Atom xsd is currently * required to be specified, but my abe optional in the future. * * @reference * @binding.atom http://localhost/examples/SCA/Atom/ContactFeed.php * @types http://www.w3.org/2005/Atom Atom1.0.xsd */ Now, I later learnt that getService >does< work, if I specify the binding type as the second parameter, but I didn't know that at first, so tried to create a local service similar to ContactFeedConsumer. The problem was that I couldn't find a way to specify a path to the Atom1.0.xsd file in the SCA/Bindings/atom directory, and ended up having to copy it into my client directory. Apparently the @types is no longer necessary either. Good news, but without updating the examples, other people are likely to be confused, too. 2. The Atom Proxy didn't honour http 301 status code I assumed this was an oversight, since other SCA proxies which make use of cURL do have CURLOPT_FOLLOWLOCATION, so I updated the code, after discussion with Graham. However I did subsequently (I know!) read the relevant RFC which suggested that the automated redirect should only be used for GETs. So if the omission was deliberate, I apologise. 3.The Atom Proxy doesn't support common HTTP headers No surprises here, this is a known problem common to all the SCA proxies which use cURL. For the server I was using, I needed to add CURLOPT_HTTPAUTH => CURLAUTH_BASIC CURLOPT_USERPWD => "$user:$passwd" CURLOPT_SSL_VERIFYPEER => false (though I should have used a more secure solution to the last of those). We've talked before about needing some sort of configuration side file to let SCA work in the real web world. I hacked my local copy to get round this for now. 4.The Atom Proxy ended catastrophically on failure I managed to break the proxy in various ways, with PHP Fatal errors resulting from failed requests where the failure conditions were not guarded. The two significant omissions were not checking that the result was not null before passing it to _fromXML(), and not checking the cURL errno before attempting to process the status code and the result, which were uninitialised. It would be nice if these conditions were returned as exceptions. 5.Server rejected the generated XML I use the following code to generate my feed entry: $xmldas = SDO_DAS_XML::create("Atom1.0.xsd"); $document = $xmldas->createDocument( "http://www.w3.org/2005/Atom";, 'entry'); $entry = $document->getRootDataObject(); /* Fill in the entry here */ return $xmldas->saveString($document); and got xml data looking like this: <?xml version="1.0" encoding="UTF-8"?> <tns:entry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:tns="http://www.w3.org/2005/Atom";> <author> <name>Caroline Maynard</name> </author> ... </tns:entry> the server barfed on this, with status code 400 and message "Unable to parse atom post entry". No doubt someone who knows namespaces better than I do will correct me, but isn't that wrong, because <author> and so on belong to the Atom namespace? Anyway, even if technically correct, this particular server didn't like it. A hand-cranked version: <?xml version="1.0" encoding="UTF-8"?> <entry xmlns="http://www.w3.org/2005/Atom";> <author> <name>Caroline Maynard</name> </author> ... identical content here </entry> was consumed OK at the server. Sorry that went on a bit. Comments? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
