>> 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.
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.
Andreas Fink
-----------------------------------------------------------------------
Ping Net GmbH, Dorfstrasse 21, 8902 Urdorf, Switzerland
[email protected] http://www.pingnet.ch/ Tel: 01-7358333 Fax: 01-7358334
Administration: admin@pingnet.ch Tech Support: support@pingnet.ch
-----------------------------------------------------------------------
Ping Net Sarl, World Trade Center, Av. Gratta Paille 2,
1000 Lausanne 30, Switzerland. Tel: 021-6411339 Fax: 021-6411310
-----------------------------------------------------------------------
Suppport freedom on the Internet: http://www.freedom.ch/
Received on Mon Nov 24 1997 - 06:47:45 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:43 MST