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 

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 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_USERPWD => "$user:$passwd"
(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(
     "";, '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"?>
   <name>Caroline Maynard</name>

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="";>
   <name>Caroline Maynard</name>
  ... identical content here

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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to