Thomas Broyer wrote on 2/7/2006, 11:21 AM: > > 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?!
I'm just reporting the arguments made in earlier months. I personally disagree with the assertion. It's not that hard, especially if you're free to reject documents that don't make sense to your server and you don't need to worry about certain other things that crop up in MIME email. > > > (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." base64 expands by a deterministic 33% and MIME requires that embedded binary data be encoded by something like base64; that's not arguable. I'm not sure what the quote is about -- the 33% expansion is for base64 encoding vs. binary encoding; the current one-resource-at-a-time scheme does have the advantage of not requiring a base64 encoding -- just use image/jpeg and send the bits over HTTP. How important this is, is certainly debatable. > > > (3) We need individual resource posting too, and given that, > > it's not 100% necessary to use compound posting; > > !? Leaving the ownership semantics to the side for the moment: You can achieve the same result with 5 HTTP requests using the core APP that you can with one HTTP request using the MIME multipart/related type. And nobody has ever seriously suggested that we shouldn't be able to simply post resources directly without multipart/related. So it's not theoretically necessary. Remember that I'm just reporting and summarizing arguments that have been made and which seemed to carry some weight in the WG (IMO). > > > (4) Given HTTP keep-alive connections, the performance penalty > > is not worth talking about. (Did I miss anything?) > > PaceCompoundEntries is not PaceBatch !!! Yes, but you can see why someone might think that it's trying to solve a similar problem. The question "why do you care how many HTTP requests you need to make?" has many answers. > > > 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. Great, and I'm looking forward to it, but it's not documented anywhere yet. > > > 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... Huh. It'd be nice if maybe a forwarding note could be put at the top of that Wiki page when new docs are created. > > > 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" "This specification does not define linking from other subsidiary parts." was what made me nervous. I don't think SOAP worried about text/css; perhaps this text was from SWA? > > 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 was thinking specifically of this: "The following additional rules apply when sending a Compound Entry over HTTP:" The rules themselves sounded like what I'd expect HTTP to do when transferring multipart/related content. So I wasn't sure if this was just reiterating the HTTP and MIME specs, or modifying them (adding constraints) for some reason, or... for example: The Content-Type multipart/related header MUST appear as an HTTP header. The rules for parameters of this header specified above apply here as well. To me, this sounds like it's saying the same thing as "the multipart/related data is sent via HTTP". Maybe it's not? > > 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"). Just because something is "related" doesn't mean it's "owned with shared liftimes". And it's not batching to say that a resource might be potentially shared. Consider the UML relations Aggregation (whole/part with no expectation of shared lifetime) vs. Composition (whole/part with lifetime of subparts bounded by lifetime of whole). My suggestion: Allow clients to specify this on a resource by resource basis, for example via link relations (rev="owner"). This would be separate from compound entries. I'd be happy to write a Pace specifically for this if there's interest. Once a compound entry is uploaded, would there be potentially a way to edit the parts separately? This would be awfully useful if for example you wanted to just edit a typo in the entry but didn't want to download and upload the 1MB embedded video associated with it. > 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. Yes, but as an extension it will be a lot more critical that whatever is proposed works well for multipart/related; type=... so perhaps a note is in order? For example if the introspection paces don't allow a type parameter, that would be a bad thing. > > > 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 ;-) I > > -- > Thomas Broyer > -- John Panzer Sr. Technical Manager http://journals.aol.com/panzerjohn/abstractioneer
