In "Is It Atompub?",James Snell discusses how an arbitrary binary filecould be posted to a feed via AtomPub, along with it's meta-data,at the same time, in a single HTTP transaction.
I'm assuming here that by "metadata", James means "stuff in the media link entry".
All James' options look like reasonable things a server CAN do. But it raises the question: how does the client knowwhich of these methods is actually supported? I guess one of the answers is via exposingcapabilities via features, which is something James iscurrently working on.
I think the answer is, if you're writing generic-ish client code, that you can't, today.
Doesn't mean you can't get close. The sequence described in Section 9.6.1of the brand spankin newRFC 5023seems to describe it pretty well. You can shortcut through that example, by issuing a PUT against theentry returned by the original POST, I assume, eliminating the secondary GET.It's just not one transaction anymore, it's two.
I'll also add that James' first option: have the server retrieve the meta-data from thebinary blob's intrinsic meta-data, seems wrong. It will require the server to know aboutmeta-data formats for all manner of binary blobs users might want to store. I think it'sfine for a server to support that, if they want, but it doesn't seem to right to assumethat every server DOES support it. But don't get me wrong, I would love to have the exif data extracted out of my photos upon upload.
So the next interesting question is, if the server DOES populate the meta-datafor the resource on my behalf, based on the resource, how do I as a generic client knowthat? Check for a non-empty atom:summary element?
BTW, I hadn't gotten a chance to extend thanks to the folkworking on the Atom and AtomPub specs, for all the work they've done over the years.Standards work is hard and thankless. Kudos all around.
Edited at 9:03pm: ops - I wanted to title this "only the server knows" not "only the shadow knows"