[links-list] Re: gzipped files - final

Petr Baudis pasky at pasky.ji.cz
Sun May 5 10:18:17 PDT 2002


Dear diary, on Thu, May 02, 2002 at 11:50:09AM CEST, I got a letter,
where Witold Filipczyk <juandon at poczta.onet.pl> told me, that...
> On Wed, May 01, 2002 at 10:48:53PM +0200, Petr Baudis wrote:
> [...]
> 
> OK. You are right. I didn't listen carefully.
> zstream for deflated and gzip and similar interface for bzip2
> in one file (protocol/compressed.c) will be simpler and better.
> For local files:
> - read them at once
> - goto decompression
> 	if not compressed return
> 	if gzipped decompress(gzip); return;
> 	if bzipped2 decompress(bzip2); return;
> 	and so on ...

Yes, that's it! :) (just please name it util/compress.c ;)

> For http:
> additional functions:
> read_http_data_gzip
> read_http_data_bzip2
> and so on

I guess it could be just read_http_data(), and saving type of compression in
struct http_connection_info - if there's any compression, we'll just
additionally decompress the data before doing anything with them.

> It is so simple, so I write it, surely ;-)

Great :).

> I have noticed, that header parsing is totally messy (you like this word,
> aren't you).

I do! :)

> My proposal is:
> 
> void (*response)()[]
> 
> array for functions - "responses" for every code get from server, eg.
> 
> HTTP/1.1 200 OK
> 
> response[200-100]() handle this
> 
> Possible codes are in range 100-599, so we need only
> 500 * sizeof(pointer) bytes of additional memory.
> But then it will be simple, fast and easilly extensible.

I think speed is not an issue here.

Seriously, I think it's too complicated and overkill just for parsing return
codes. First, it'll be basically full of NULLs, second frequently you want to
handle whole ranges of codes identically, and third there're no problems with
the current way (except that the code looks a bit ugly and needs some tidyup ;)
and I think it's convient enough. When scalability of the current mechanism
will become an issue, we could do something, but IMHO it'll just make our life
harder now..

> In similar way for headers:
> - function for Date:
> - function for Server:
> - function for every known header
> 
> Default headers in sorted array.
> With binary search we get either index of function, which handle given header,
> or we get to know that this header is not handled yet.

This sounds a bit better and more usefull, but still ditto, IMHO :). Maybe I
would accept patch for this, but I'd certainly like people to work on more
important things ;)).

> Development will be simple, easy and enjoyable :)

All for that! :)

-- 
 
				Petr "Pasky" Baudis
 
* ELinks maintainer                * IPv6 guy (XS26 co-coordinator)
* IRCnet operator                  * FreeCiv AI hacker
.
Object orientation is in the mind, not in the compiler. -- Alan Cox
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
-- 
Unsubscribe: send email to links-list-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the links-list mailing list