Re: delta encoding and state management

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <CAOdDvNoOnscRCA54n07Suxe9UQieq32SkwvMxNnEdSnK94s_PA@mail.gmail.com>
, Patrick McManus writes:

>> As I said, I think that if the state itself is never larger than a request
>> and substitutes for the request, it's not that big of a deal.
>
>honestly, the trend in ram prices [...]

I think both of your perspectives are too near-sighted here.

The protocol you should be working on should be the one which
still works when most middle-class homes, not only in the western
world, but also in India and China, have fibre to the home at
speeds of 1Gbit/sec and above.

In that world, a major piece of global news, be it a naked breast,
an geophysical event or a shot politician, is going to make the
traffic spikes we have seen until now look tame.

HTTP is a very assymetric usage protocol, and therefore any amount
of state that the server _has to_ retain for a client must justify
it's existence, byte for byte, against the scenario where 10% of
the world want to access the same URL.

HTTP/1 allows you to deliver content without committing any per-client
state, beyond the TCP socket, and that is not a "degraded mode",
that is the default mode.

If your HTTP/2 proposal cannot do that, you're working on the wrong
protocol.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 23 January 2013 13:19:45 UTC