Yes, they certainly do.
Snell's draft explicitly says this is not meant to replace pipelining,
but there sure are a lot of similarities. Pipelining also allows for
multiple requests to be sent over a persistent connection without
waiting for a response, so it achieves many of the benefits of
Multipart/Batch. It's interesting that Snell's example show multiple
POST requests being batched together -- pipelining non-idempotent
methods is something a client SHOULD NOT do per RFC 2616, Section
8.1.2.2.
One might think of Multipart/Batch as an alternative to _bulk_docs,
but then
Applications processing Multipart/Batch parts MUST NOT assume that
any relationship or dependency exists between the individual parts
of the batch message.
that kinda screws with the all_or_nothing option.
Adam
On Jun 11, 2009, at 4:22 AM, Rory McGuire wrote:
This allows submission to multiple URLs. Do HTTP/1.1 persistent
connections allow that?
On Wed, 2009-06-10 at 21:24 -0700, kowsik wrote:
How is this different from HTTP/1.1 which supports persistent
connections + multipart MIME uploads which allows for a whole bunch
of
MIME entities to be sent in the same request?
I didn't read the draft, but looking at the examples (and the blog
comment) I'm not sure what this is trying to solve and why
multipart/batch is required.
K.
On Wed, Jun 10, 2009 at 8:20 PM, Noah Slater<[email protected]>
wrote:
Hey,
This blog post from James Snell should be interesting:
http://www.snellspace.com/wp/?p=991
Thoughts about implementing this?
Best,
--
Noah Slater, http://tumbolia.org/nslater
