Re: [hybi] Payload only compression extension, again

I can change my proposal to accept last blocks (blocks with BFINAL=1) to
allow use of java.util.zip. In my proposal, receiver expects 3 header bits
0b000 (and padding to byte boundary) on the tail of the application data
portion. Not to complicate receiver logic much, I'd make change like this
- sender: send(<compressed data flushed with Z_FINISH> + "\x00")
- receiver: inflate(received_data + "\x00\x00\xff\xff"). every time inflater
encounters end of stream (the last octet of a last block), renew inflater
and keep decompressing the remainder.
or
- sender: send(<compressed data flushed with Z_FINISH>)
- receiver: inflate(received_data). every time inflater encounters end of
stream, renew inflater and keep decompressing the remainder. if the end of
received_data is not end of stream, inflate("\x00\x00\xff\xff").

Either algorithm works for Z_SYNC_FLUSH-ed and "\x00\x00\xff\xff" stripped
frame, too.

Takeshi

On Tue, May 3, 2011 at 07:52, Greg Wilkins <gregw@intalio.com> wrote:

> On 3 May 2011 08:02, John Tamplin <jat@google.com> wrote:
> > My point was I see little value in having a compression extension which
> > starts the compression state afresh with every frame, as on real-world
> > applications this gives poor performance.
>
> +1
>
> My extension is more about prototyping plugable extension that work
> well in a chain of extension, plus handling the negotiation and per
> frame issues.    I'll follow the lead of the others/experience on the
> exact algorithms to use (even though I think that is going to cause me
> endless headaches with mismatched licenses and getting IP audits done
> at eclipse :(
>
> cheers
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>