What works

The test_contact_feed.php example works. It creates an entry, uses getService to get a proxy to the feed supplier on the far end, ContactFeed.php, and uses create, retrieve, update, enumerate and delete. The feed supplier contains a reference to a service which will hold the data either in xml files or in a database. It's a one-line change to switch from one to the other (point the reference at either ContactFile.php or Contact.php)

I tried the feed that is produced in Awasu (a feed reader I like) and it read and formatted the feed OK so the format looks good. 

Known defects

I have the following collection of known problems that Megan Beynon told me about but sometimes the description I have is a little cryptic. It's still worth putting them down here I think. I could raise them in PECL, but for the moment the code is not ready to put into a release, so I think PECL bugs would be a bit too heavyweight.

• When errors occur we sometimes just fail quietly with the effect that php sends back a 200 return code which the far end interprets as success when it is in fact far from it. This problem actually occurs with the other bindings too and there is a pecl bug open for it.
• retrieve gets one entry and enumerate gets more than one but there is some confusion in the code paths
• isAtomRequest relies on the content type but no one does it. 
• we don't handle http code 415
• we have problems with conflict exception. There is something we could check in the infrastructure - could handle in the proxy rather than send back Condition failed
• the spec says that any 400/500 codes must have a human-readable explanation
• we are adding in the atom xsd clumsily - there is a prototype on the rss binding where the das is made appropriate for atom
• we don't do paging
• we have had problems with links and ids
• we used to generate the location of the resource
• there can be several link fields with attributes
• info will get through even if we don't handle it - the component will get it
• getService should be able to directly reference a server-side component 
• always get an sdo not xml - is it possible to specify?

Items from the spec

A trawl of the atompub spec showed a number of areas that have not really been implemented at all. Sorry about this - these are also wildly cryptic.

• real atom server with category
  
• specific content type 
• slugheader 9.6
• URI vs. IRI
  
• will support a custom header not CRUD+E but something else
• POST atom feed doc to a collection behaviour is undefined
• spec says something about xml:base and xml:lang
• remove the load of xhtml.xsd when we load atom.xsd - make it optional
• deleting media resources is a more complex process
• spec allows POST application-xml which conflicts with the soap binding
• If the post/put/get is to a invalid URI we now handle this the SCA default not the spec way
• must allow foreign markup eg RELAX-NG
• need to retrieve entry resources that are not atom e.g. jpeg but rules about atom format must be exactly right 
• something about SDATA
• collection paging with next within 
• etags and being able to tell if an entry is updated
  
• must be able to post to a collection to create a resource