we'd love to see PaceCompoundEntries as an extension and ensure that the base had enough in it to ensure that this type of extension was not at odds with APP.
as well as having a discussion on the technical merits of PaceCompoundEntries we are also interested in seeing if anyone else is having interop issues with the current treatment of media resources. I'd like to walk through the example in the specification (section 12), which caused us a fair amount of confusion and use it to also highlight some of our current problems. > 12. Atom Publishing Protocol Example > > This is an example of a client creating a new entry with an image. > The client has an image to publish and an entry that includes an HTML > "img" element that uses that image. In this scenario we consider a > client that has IRIs of two collections, an entry collection and a > media collection, both of which were discovered through an > introspection document. The IRI of the entry collection is: > > http://example.net/blog/edit/ > > The IRI of the media collection is: > > http://example.net/binary/edit > > First the client creates a new image resource by POSTing the image to > the IRI of the media collection. > > POST /binary/edit/ HTTP/1.1 > Host: example.net > User-Agent: Thingio/1.0 > Content-Type: image/png > Content-Length: nnnn > Title: A picture of the beach > > ...binary data... > > The member resource is created and an HTTP status code of 201 is > returned. > > HTTP/1.1 201 Created > Date: Fri, 25 Mar 2005 17:17:11 GMT > Content-Length: nnnn > Content-Type: application/atom+xml > Location: http://example.net/binary/edit/b/129.png I have edited what is in the current draft and removed the content body as this is optional and is not returned by our server's implementation. So now what is the client to do to get the readonly url. As far as we can make out the only option that it has is to retrieve the media collection (potentially paging) until it finds an entry that has this returned location as its "edit link". It can then pull the content/@src to get the url to use for its post. This seems like a lot of work to us and has forced us to go down an alternative route. The client coders balked at this. > The client then POSTs the Atom Entry that refers to the newly created > image resource. Note that the client takes the IRI > http://example.net/binary/readonly/129.png and uses it in the 'img' > element in the Entry content: > > POST /blog/edit/ HTTP/1.1 > Host: example.net > User-Agent: Thingio/1.0 > Content-Type: application/atom+xml > Content-Length: nnnn > > <?xml version="1.0" encoding="utf-8"?> > <entry xmlns="http://www.w3.org/2005/Atom";> > <title>What I did on my summer vacation</title> > <link href="http://example.org/atom05"/> > <id>urn:uuid:1225c695-ffb8-4ebb-aaaa-80da354efa6a</id> > <updated>2005-09-02T10:30:00Z</updated> > <summary>Beach!</summary> > <content type="xhtml" xml:lang="en"> > <div xmlns="http://www.w3.org/1999/xhtml";> > <p>We went to the beach for summer vacation. > Here is a picture of the waves rolling in: > <img > src="http://example.net/binary/readonly/129.png"; > alt="A picture of the beach." > /> > </p> > </div> > </content> > </entry> > so the final post is then made, but let's say that the user wants to now categorize the picture. They want to tag it with "beach" and "waves", describe it etc. Here we are stuck again as we posted the picture to a media collection and media collection entries cannot have their meta data edited. We could post a reference to this to an entry collection, but which entry collection would we post it to??? .... we could instead have stored the image in an entry collection. This appeals to us as we can then provide the necessary meta data. Our client and server approach is now defaulting to this as we want meta data with media resources. However will other clients know to post pictures in our entry collections? I would guess not and now the user gets confused. When posting with our client the images get uploaded to a place where they can have meta data whereas other client do not let them do this. Again, is anyone else seeing similar problems? On 2/7/06, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > 2006/2/7, John Panzer <[EMAIL PROTECTED]>: > > > > I think compound posting is conceptually a reasonable extension, but the > > Pace referenced has a lot of problems that will cause interop issues. > > As I noted earlier, I thought a little bit more about it and the Pace > doesn't reflect that, given that it's (now) intended to be an > extension to the protocol. > > > The arguments agaisnt requiring in the core were (IIRC): > > (1) Multipart MIME is hard; > > Are you sure?! > > > (2) Requires 33% expansion of binary content via base64 encoding; > > Absolutely not! > > "Another solution would have been to define extension elements to the > Atom Format to contain Base64-encoded resources. This means however > reinventing part of Multipart/Related." > > > (3) We need individual resource posting too, and given that, > > it's not 100% necessary to use compound posting; > > !? > > > (4) Given HTTP keep-alive connections, the performance penalty > > is not worth talking about. (Did I miss anything?) > > PaceCompoundEntries is not PaceBatch !!! > > > The Pace http://www.intertwingly.net/wiki/pie/PaceCompoundEntries has > > some problems. > > It mandates that clients MUST support this. > > As I noted earlier, I found a solution to that MUST. > > > It talks about Multipart/Relative(?) seemingly interchangeable with > > Multipart/Related. > > Hmm, right, typo ;-) > > My attempts to update the Pace (to explicitly say that it's withdrawn > and that the use of multipart/related is now intended to be an > extensino to the protocol) was rejected, so I won't even try to update > it to fix that typo... sorry for the inconvenience... > > > It doesn't spec how to link (for example) from a subsidiary CSS stylesheet > > to a related subsidiary background image via cid:. > > "Implementations MUST resolve "cid:" URLs appearing in the Atom Entry > Document. They also SHOULD resolve such URLs in text or XML body parts > (i.e. parts whose Content-Type header value is an XML Media Type, > begins with "text/" or ends with "+xml"). > To resolve "cid:" URLs to the final public URIs of the aggregated > resources, implementations MAY use text replacement inside the Atom > Entry Document before parsing or processing it" > > OK, the last sentence only deals with "Atom Entry Document", but > nothing prevents an implementation to use that "algorithm" (not really > an algorithm, isn't it?) for other "text or XML body parts". > > /me: spec it clearly when I'll write an I-D... > > > It rules out Content-Transfer-Encoding but you really do want to > > be able to compress this stuff if you're base64-encoding it... > > HTTP has Transfer-Encoding for that purpose. > > > in general it tries to rewrite a bunch of HTTP rules. > > Could you be more precise, I'm open to changing anything that could > lead to an improvement and easy adoption. > > I think I adapted (with some cut & paste) SOAP Messages with > Attachments for everything related to HTTP. > > > It assumes a tight coupling of resources to entries, which isn't very > > flexible. > > Again, PaceCompoundEntries is not PaceBatch ;-) > > Multipart/related shouldn't be used for batching (where "parts" are > not necessarily "related"). > A multipart/* structure could be used for batching, but I don't think > multipart/related would be a good choice. > > > Finally, it doesn't specify how to advertise this capability. > > Many other Paces have been written for that. Among them, > PaceCollectionsAcceptedMediaTypes and PaceCollectionsAccept would > allow a server to advertise it accepts > multipart/related;type="application/atom+xml" entities. > > > (I'd suggest Multipart/Related to appear in the Accept: header > > +1 > > > and for servers to support the OPTIONS verb if they want to support > > any extensions.) > > This is not always possible: > http://www.mnot.net/blog/2006/01/09/options > Some software have been fixed, but new version are not always > (rearely?) deployed on shared hostings. > > I'd rather suggest something in the service/introspection document > and/or using Accept as a response header as well (sent in response to > a GET to the collection URL, in case you didn't go through a service > document). > > > It's generally not written as an extension but as a core APP capability; > > I think it would need to be rewritten as an extension in order for a > > discussion about interop to be useful. > > I didn't have time for that (and I don't think I'm really good at it) > but my goal is to have an I-D (one day). Give me a month or so, and > don't hesitate to badger me ;-) > > This is a call for people interested in implemented it, in order to > share experiences and do some interop tests ;-) > > -- > Thomas Broyer > >
![http://example.net/binary/readonly/129.png"](http://example.net/binary/readonly/129.png"){kind=link}