W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Updated Delta+BOHE Impl in Java

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 9 Apr 2013 13:52:26 -0700
Message-ID: <CAP+FsNc=HzMcCUivZdqt1nA6oZ_U2sM6mPp+-3TKDQ+4Y3TbGg@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
yup.
-=R


On Tue, Apr 9, 2013 at 10:58 AM, James M Snell <jasnell@gmail.com> wrote:

> I pulled the values from Roberto's most recent draft here [1]. I
> believe he put it together from the corpus of sample data that's been
> collected in the github repo.
>
> [1] http://tools.ietf.org/html/draft-rpeon-httpbis-header-compression-03
>
> On Tue, Apr 9, 2013 at 10:37 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > This is great news.
> >
> > Out of interest: Where did you derive the values you used to build
> > your Huffman tables?
> >
> > On 9 April 2013 10:24, James M Snell <jasnell@gmail.com> wrote:
> >> I have updated my experimental Delta+Bohe java implementation to match
> >> the current draft of the specification and Roberto's current delta
> >> iteration. I still have to patch this in to the compression-test stuff
> >> but the code is functional.
> >>
> >>   https://github.com/jasnell/http2
> >>
> >> Requires maven to build. Dependencies are light. Still needs a ton of
> >> work and I have not even started working on performance optimizations.
> >> It's a pretty straight forward port of everything Roberto has done in
> >> the python impl.
> >>
> >> The one bit this does add is multi-type header values. The types
> >> supported are String, Number, Datetime and Binary. Strings can be
> >> either UTF-8 or ISO-8859-1. If they are ISO-8859-1, they can be
> >> Huffman coded using Roberto's static code. I am using an different
> >> static dictionary of predefined header values tho.
> >>
> >> General takeaways ..
> >>
> >> 1. The implementation is not that difficult to do and seems to perform
> >> reasonably well.
> >> 2. The additional types are very useful and add minimal additional
> >> complexity to the implementation.
> >> 3. I'm generally not convinced that we really need the huffman coding.
> >> Yes, it saves a handful of bytes here and there but it does add
> >> additional complexity. I can live with it tho. If we keep it and we
> >> decide to allow for UTF8 header values, then we need to come up with a
> >> static huffman coding that includes the extended UTF8 character
> >> support.
> >> 4. Performance seems reasonable overall.
> >>
> >> I'm going to be working on implementing HeaderDiff next. Hopefully
> >> I'll have the time to have that done by this Friday.
> >>
> >> - James
> >>
>
>
Received on Tuesday, 9 April 2013 20:52:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC