Re: SPDY Review

Interesting, thorough and well-considered review.  A few opinions
included inline:

On 7 June 2012 07:18, Martin Nilsson <nilsson@opera.com> wrote:
>  By adding priority information to the requests the server can take
>  active decision in which resource to send first.

I don't think priority is as big a deal as people are making out.  On
the contrary, it's a distraction.

1. The server is probably more likely to know what resources need to
be acquired first.
2. The client has the ultimate control over what resources are
requested, so they already have control over priority (if resource A
is more important than resource B, just don't request resource B).

Beyond this, the main reason you might use priority is for large
concurrent representation (i.e., file) transfers.  Bittorrent has this
feature for torrents with multiple files.  The utility for HTTP is
somewhat limited.  That's not to say that it isn't a useful feature,
but I don't see it as a core necessity.

>  [...]  While the concerns is valid, flow control looks like
>  overkill to something where a per-channel pause control frame could
>  do the same job with less implementation and protocol overhead.

The problem with a pause frame is the time that it takes to propagate.
 During that time, you can end up getting a lot of data that you can't
do anything with.  Flow control is a well understood mechanism that
solves the problem.

I'm going to argue that flow control is the necessity and priority is
the unnecessary feature gold plating.

>  The problem with [asynchronous headers] is that it creates a situation where a
>  potentially critical header for the interpretation of the content is
>  sent last, thus forcing the receiver to put data processing on hold.

If you read the guidance on trailing headers (footers?), the key
message is that they should not be critical.  The same guidance should
apply to any asynchronous headers.

The utility of a trailer can be significant.  For instance, if you
have to calculate a hash of the representation, they represent a
significant performance gain.  In this case, I can imagine wanting to
send supplementary information after the representation; Link headers,
for instance.

> 2.6. Push

Is not sufficiently justified to warrant the significant change in
protocol semantics.

Received on Thursday, 7 June 2012 16:12:54 UTC