rob yates wrote: > 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. hi,
where is this edited version available for viewing? > So now what is the client to do to get the readonly > url. > in that case it should also have no Content-Type header returned and length set to zero (or not present) i.e. HTTP/1.1 201 Created Date: Fri, 25 Mar 2005 17:17:11 GMT Content-Length: 0 Location: http://example.net/binary/edit/b/129.png > 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. > IMHO: that is not very elegant if not "hackish" ... thanks, alek > > > >> 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 >> >> >> > > > -- --- Memorable Quote from Firefly (105. Out Of Gas) -Ship like this, be with you until you die -That's because it's a deathtrap
![http://example.net/binary/readonly/129.png"](http://example.net/binary/readonly/129.png"){kind=link}