- From: Mike Belshe <mike@belshe.com>
- Date: Sat, 9 Jun 2012 10:03:32 -0700
- To: Martin Nilsson <nilsson@opera.com>
- Cc: Roberto Peon <grmocg@gmail.com>, ietf-http-wg@w3.org
- Message-ID: <CABaLYCtMbCcFMDzJxcHQs49f5iAtL7=hR-b51tvXx=nW=HBNFQ@mail.gmail.com>
On Fri, Jun 8, 2012 at 9:29 AM, Martin Nilsson <nilsson@opera.com> wrote: > On Thu, 07 Jun 2012 21:57:38 +0200, Roberto Peon <grmocg@gmail.com> wrote: > > >> Can you tell us more about your or Opera's operational experience with >> equivalent features? >> I'd be rapt at any such presentation! >> >> > We have Opera Mini that uses several different protocols, both similar to > HTTP as well as of the persistent TCP connection type. These are all binary > protocols using different versions of request-response, RPC, push features, > as well as compression of different sorts. We have Opera Turbo, which is > essentially a modified HTTP with prioritized, out-of-order pipelining and > some simple compression. Finally we have integrations with different 3rd > party technologies, some of which are mentioned on the press release pages > http://www.opera.com/press/**releases/2004/11/04/<http://www.opera.com/press/releases/2004/11/04/> > http://www.opera.com/press/**releases/2007/02/06/<http://www.opera.com/press/releases/2007/02/06/> > > Not really an answer to your question though, I'm afraid. I would need > more time (and meetings) to collect that... I'd be interested to hear if Opera would ever open-source these protocols and any reasons for why or why not that Opera would be willing to disclose. > > > >> I agree totally that better approaches on the compression side likely >> exist. >> I'm surprised at the numbers, though. Our experience in the past was that >> headers were significantly more compressed than you're seeing here. >> >> > I'm using the same data as the http://www.eecis.udel.edu/~** > amer/PEL/poc/pdf/SPDY-Fan.pdf<http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf>and when using the evaluation set they use I actually get somewhat better > compression values (probably due to better header normalization). I feel like we're getting caught up in noise here; looking at single block compression is uninteresting. In real world cases, with repeated cookie blocks, the algorithm does great, at over 85% compression. We can do incrementally better and I'm not opposed to that. But the use of the dictionary or not is trivial and doesn't matter in the overall picture. Is there something else you wanted to propose? Mike > > > /Martin Nilsson > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > >
Received on Saturday, 9 June 2012 17:04:53 UTC