John Panzer wrote: > James M Snell wrote: > > John Panzer wrote: > > > Quote from this document: > > > "First the client creates a new image resource by POSTing the image > > > to the IRI of the media collection." > > > > > > So, given just the IRI of a Collection resource that presumably > > > represents my "main" feed/blog/whatever, how do I get the IRI of the > > > "media collection" to use for my first POST? > > > > How the multiple Collection IRI's are discovered is an Introspection > > task that would be defined in a separate I-D as has been discussed in > > other recent threads. > > Hmm. I assume that would at best be a document produced after thid I-D > (otherwise, they could be consolidated now). I think this is > operationally equivalent to moving the ability to post such compound > documents out of the core APP. I'm not that concerned about more > complex discovery, etc. but it appears to me that this proposal is > throwing the baby out with the bathwater. If I'm misreading the > situation, please let me know. > > Back when we were starting this whole IETF WG thing, there was general > consensus that the publishing protocol needed to support > XHTML-plus-picture-resources as part of the core. I don't think that's > changed, though please feel free to let me know if you think this is no > longer the case.
Without multipart/related, you won't be able to do that without some configuration of your client, unless the spec: * defines that a collection can contain both "media" resources and entries, so you'll post your images and then your entry to the same collection. * requires an entry+media couple and defines that the media collection is where you will post anything that is not an entry and the entry collection where you will post entries, so that there is no ambiguity. As the WG (and myself) believe multipart/related shouldn't be in the core protocol, I expect end users to have to configure their blogging clients telling them "this is where you will save images attached to my entries"; at least until there is an extension or support for multipart/related (I'll write an I-D based on PaceCompoundEntries). Back on the two options above: * a collection where you post everything: this prevents photoblog collections you post an image, the server extracts EXIF metadata and creates an entry with <content src="..." /> as there is no more distinction between what is an entry and what is an "attached" resource. * entry+media couple: this is where Luke's proposal tends (provided that entrypost and mediapost links are zero-or-one in a feed or entry). Another option would be to have an "accept" property on collections telling clients what kind of resources they can post (using mediaranges, à la PaceCollectionsAcceptedMediaTypes). Clients would then choose the collection based on the mediatype of the resource they want to post, using a process similar to HTTP negociation. However, this option doesn't solve every issue either, it needs grouping of collections, otherwise you can't distinguish a photoblog collection from a "media" collection in the following scenario: <collection title="Entries" accept="application/atom+xml" href="..." /> <collection title="Photoblog" accept="image/jpeg" href="..." /> <collection title="Entry images" accept="image/jpeg,image/png" href="..." /> -- Thomas Broyer
