Re: bohe and delta experimentation...

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Jan 16, 2013 at 5:07 PM, James M Snell <[e-mail]> wrote:

> After going a number of scenarios with bohe using a variety of
> stream-compression scenarios it's painfully obvious that there is really no
> way around the CRIME issue when using stream-compression. So with that, I'm
> turning my attention to the use of Roberto's delta encoding and exploring
> whether or not binary optimized values can make a significant difference
> (as opposed to simply dropping in huffman-encoded text everywhere).
>
> I'm starting with dates first...
>
> Right now, dates in http/1 requests are rather inefficient. The existing
> date-time format wastes a significant amount of space, albeit across only a
> relatively few headers. On the plus side, these tend to compress well, but
> given that the dates change frequently request-to-request, they will be
> short-lived in the delta context.
>

Why do HTTP request messages have dates in them anyhow?

If they do not cause a state machine to behave differently then lets get
rid of them.

Dates that are content metadata are useful but putting the time in a
synchronous protocol has always seemed rather silly to me. The only use I
can see is to find out if the requester can config their machine to have
the right TOD on the clock. If that is all we are worried about then DNS
type 32 bit dates would be fine. DateTime in the DNS actually wraps every
UNIX epoch.

Given that we could eliminate the date altogether much of the time, having
the format wrap every 65 years or so does not seem a big problem to me.


Given that the universe we are in will wear out in a finite time it seems
unnecessary to use more than a 64 bit count of miliseconds or such. that is
only 8 bytes and easier to manage than the proposed format.

-- 
Website: http://hallambaker.com/