Re: Features

On Mon, 24 Nov 1997, Andreas Fink wrote:

> >> However it gets developed, use some easy "replacable" way to implement the
> >> compression/decompression. Some type of negotiation header (at the start of
> >> a persistent connection) wouldn't go amiss either...
> >
> >Yes.. This would be good.. It shouldn't just be for intercache. It should
> >also allow savvy browsers.. :)
>
> Make shure you dont use any code which are covered by patents. Using LZH
> for example would not be a good choice. This is especially essential if you
> are thinking to bring compression into the browsers as an option. Browsers
> are usually commercial software and if they have to license from the
> patents owner, it would be a pitty. It would slow down the implementation
> of the decompression in the browsers because the manufacturers have to
> hassle about legal stuff.

I posted a message where I benchmarked LZO, GZ, and BZ2.. None are covered
by patents..
 
> Also I dont know if its very clever to have more than one compression
> algorythm active. Imagine if you have different squids compressing with
> different preferred algorythms. You might come to the situation where you
> want to fetch a file compressed but you dont have the decompressor. Or you
> can decompress but your storage usually works with another compression
> algorythm. So choosing a good one as strongly preferred one for me looks
> best. It also saves the worry about having to handle the compression
> technique in the storage area.
>

Yes, after benchmarking, I have decided that straight up LZO will do very
well.. It has superfast decompress.
Received on Mon Nov 24 1997 - 10:56:46 MST