Re: PaceBatch and pipelining

[fmantek <fmantek@xxxxxxxxxx>]

I like to bring up another argument in favor of a batch mechanism
build into the protocol. While it is all fine and dandy for the sake
of the protocol that HTTP supports something that in a constructed
case leads to very similiar client performance, it is not, in my
opinion, taking all facets of the problem into account.

As a mostly disconnected scenario, updates will most likely be
collected over time. Take ecto or similiar blog publishing apps. They
allow you to create a couple of posts, and at one point in the future
submit them to your server.

If your the protocol supports batch updating, i can easily envision
what the temporary storage format is, how my application takes
advantage of it etc. It's going to be a piece of cake to write this.

Give programmers a simple and well documented batch API, and they will
start using it, thereby creating nicer to use, more in line with the
ideas behind disconnected life, better applications.

That is an important benefit to me. I can see tons of applications
that benefit from this, especially in the low end device case.

Just 2c

Frank

On 6/28/05, Mark Baker <distobj@xxxxxxx> wrote:
> 
> On Sun, Jun 26, 2005 at 10:25:48PM -0700, Tim Bray wrote:
> > On Jun 26, 2005, at 7:40 PM, Mark Baker wrote:
> >
> > >Moreover, the
> > >problems with batching non-idempotent requests isn't at all
> > >specific to
> > >HTTP pipelining, it's just inherrent to any batch mechanism, including
> > >PaceBatch.  That is, if you POST a BatchRequest with two app:Post
> > >requests embedded, you're going to have exactly the same issues as
> > >with two pipelined HTTP POST requests.
> >
> > Except for, PaceBatch recognizes that partial success is a
> > possibility and specifies measures (no re-using URIs) to limit the
> > damage.
> 
> Hmm, I can't seem to find that in the Pace, but it seems like it could
> be a useful restriction.  Is there any reason we couldn't just provide
> the same advice when using pipelining?
> 
> >Curious: is there any prior art in using HTTP to do this
> > kind of thing?
> 
> Dunno.
> 
> > >So I'm -1 on PaceBatch, but I'd support APP calling out the use of
> > >HTTP
> > >pipelining for batching purposes (with a caveat about going against
> > >the
> > >SHOULD NOT recommendation from 2616, of course).
> >
> > So, let me see... we could adopt an approach which is limited to HTTP
> 
> Last time I checked, APP was still HTTP based (8-), so I see no problem
> in leveraging another existing, battle tested, widely implemented,
> HTTP-specific feature.
> 
> > while flying in the face of a SHOULD in its RFC,
> 
> I responded to that point already, so won't repeat it here, except to
> say that I believe this Pace should say that BatchRequests SHOULD NOT
> include non-idempotent operations (such as app:Post).
> 
> > one which which breaks no rules and is potentially usable on a wide
> > variety of protocols including HTTP.  Seems like a no-brainer to me.
> >
> > (Assuming we believe there's a real quantitative optimization to be
> > had). -Tim
> 
> Yes, that's good to keep in mind.
> 
> Mark.
> --
> Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
> Coactus; Web-inspired integration strategies   http://www.coactus.com
> 
>