Re: PaceBatch and pipelining

["Roy T. Fielding" <fielding@xxxxxxxx>]

On Jun 28, 2005, at 1:25 PM, Tim Bray wrote:

> I think the soft metric approaches or exceeds the hard metric in 
> importance.  The Web didn't succeed because it had optimal 
> performance, it succeeded because it was *easy*.  HTML didn't succeed 
> because it was a high-efficiency markup language, but because it was 
> easy.  Blogging didn't succeed because...   RSS didn't succeed 
> because... etc etc.  If batching is going to provide a simpler 
> programming/implementing model than HTTP magic, I'm for batching even 
> if it doesn't improve performance.

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.).  What on earth are you talking about when you
say "simpler programming/implementing model"?

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).  It sure isn't evident in the WG charter.
If batching goes in without justification then I won't recommend
the protocol for use on the Internet, since batching is harmful to
HTTP in general due to its interference with intermediaries.

If batching doesn't significantly improve performance, then common
sense says leave it out of the APP design.  If you want to make a
case for it, then explain (in detail) the use case and its frequency
for Atom interactions, keeping in mind that you don't need an
Internet standard to deploy vendor-specific optimizations.

....Roy