Re: PaceBatch and pipelining

[Tim Bray <Tim.Bray@xxxxxxx>]

On Jun 28, 2005, at 2:21 PM, Roy T. Fielding wrote:

> > I think the soft metric approaches or exceeds the hard metric in  
> > importance.
...
> We are talking about comparing HTTP pipelining (already implemented,
> zero deployment cost, graceful degradation when not present) versus
> tunneling multiple Atom requests through HTTP POST (not implemented,
> requires universal support, already shown to be poor design in SOAP,
> specifically frowned upon by past IETF specs, egregious cost to
> intermediaries, etc.).

As for "not implemented, requires universal report", the  
implementation is trivial.  If anyone with implementor credibility  
*really* disagrees I'll go write the code to prove it.

as for
- already shown to be a poor design in SOAP
- specifically frowned upon...
- egregious cost to intermediaries

You need to bring some evidence to bear to support those claims.  I  
don't a priori disbelieve them, although the third smells wrong.

>   What on earth are you talking about when you
> say "simpler programming/implementing model"?

I'm saying this:  If I wanted to post 10,000 new entries I could sit  
down and write the code right now this minute to pump them out into  
an <batch> element and send them off with a POST and parse the  
results, and I have a high confidence that it would work.  Without  
<batch>, I'd have to go and learn how to do the HTTP magic and then  
I'd have to experiment to figure if it provoked any performance  
anomalies with the Web server I wanted to use.  BTW, the world has an  
excellent understanding of the performance characteristics of pushing  
a great long stream of data into an HTTP server and having it  
dispatch the stream to code to pick it apart.

I believe strongly that things that are simple and obvious and easy  
and predictable are good.  The <batch> element meets those criteria,  
plus it will work fine when I want to transmit some batches but  
[gasp] don't want to use HTTP.  Anybody who wants to whine  
religiously about "but Atom is an HTTP protocol" is within their  
rights but it is egregious stupidity to pretend that it isn't an  
advantage to be useful in the context of multiple protocols.

> All that without a single use case to tell if the desire for this
> feature is even applicable to standardization (i.e., needs independent
> implementations).

Agreed.  When Google says "We think we need this" I tend to cut them  
some slack, but we do need a better characterization of the test- 
cases and trade-offfs.

> If batching doesn't significantly improve performance, then common
> sense says leave it out of the APP design.

Rephrase: "If batching doesn't significantly improve performance or  
simplify the programming model, then common sense says leave it out  
of the APP design."  -Tim