Re: bohe and delta experimentation...

On Wed, Jan 16, 2013 at 5:10 PM, James M Snell <jasnell@gmail.com> wrote:
> On Wed, Jan 16, 2013 at 2:47 PM, Nico Williams <nico@cryptonector.com>
> wrote:

> One of the nice thing about the strawman encoding I used is that it is a
> field-for-field representation of the RFC3339 timestamp. It encodes exactly
> the same information and can represent the full range of dates supported by
> the date-time construct. Other variations may shave off one or two
> additional bytes but either lose information or are far more limited in the
> values they can express. Suppose we decided to adjust the millisecond field
> to 10 bits as you suggest we have a worse case of 9-bytes, best case of 6.
> Seems like a reasonable compromise to me.

The variations I mentioned also encode the same information without
losing anything at all.  The downside of going the julian day or
seconds since epoch approaches is that they require more computation,
but I think we can burn those CPU cycles since they won't incur many
cache misses -- it's fast and saves bytes on the wire where it
matters.

The question is: is it worth the trouble?  I don't have an answer to
that, but I'm inclined to say that yes, we should represent dates/time
in an already very small format.


>> Where cookies bear encrypted session state you won't be able to
>> compress them at all.  And it's not like the server can't do the
>> effort to set maximally-compressed cookies -- it should!  IMO: leave
>> cookies alone.
>
> Yeah, that's what I suspect also. Allowing for binary cookie values can
> allow us to avoid extra bits on the wire but compression here typically
> doesn't help for these at all, regardless of how optimized our code tree is.

Right, because cookies are mostly either randomly generated crap or
encrypted state, and those can't compress *at all*.

Received on Wednesday, 16 January 2013 23:21:21 UTC