Re: PaceBatch and pipelining

[Mark Baker <distobj@xxxxxxx>]

On Tue, Jun 28, 2005 at 08:36:48AM +0200, fmantek wrote:
> I like to bring up another argument in favor of a batch mechanism
> build into the protocol.

Just to put this in context...  by virtue of APP being HTTP/1.1 based,
it already has a batching mechanism; HTTP pipelining.  PaceBatch would
be a second batching mechanism.

>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.

I think that could be done without batching, as the Pace suggests;

  An alternative form might be to provide batching of operations of a
  common type, via the appropriate HTTP METHOD on a collection. In this
  model, a POST to a collection could be a batch request containing
  multiple entries to create, or a PUT would contain multiple entries to
  modify, or a DELETE could identify multiple entries to delete. This
  might result in up to 3 requests being used where one would work with
  the proposed model, but still provide a significant benefit over
  sending as discrete requests.

I could probably be convinced to support such an approach ...  at least
if pipelining is ruled out as unsuitable. 8-)

> 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.

Sounds good to me too.  But I don't know why pipelining (or failing
that, the other approach above) can't be used to do all that, at least
in the general case.

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com