Hi, On Mon, Nov 05, 2007 at 10:46:09PM +0000, place wrote:
What would you think of something like the code I have attached?
I'd like to have gzip decoding in dillo2.
I had looked at the gzip portion of the i18n patch, just intending to put it in my own copy, but it was unsatisfactory in some ways, so I ended up changing the whole thing and this was the result.
It looks quite advanced and that giving it a second pass on simplicity/elegance it'd be ready.
Bad: 1. I stuck an awful lot of things into CacheEntry_t.
Yes. IMO, having only: Dstr *EncodedData; char *Encoding; added to CacheEntry_t is cleaner. (we can add a Dstr_get_size() if necessary).
2. During the downloading/decoding process, there is Data and DecodedData. It gets fixed up afterward, but it means that things like trying to view source during downloading does not work. I imagine the fix being something like changing Data to RawData, DecodedData to Data, freeing RawData after download is complete, and looking at all of the current references to Data to figure out which of those they should use. But I'll leave that for after I find out what you think of what I have so far.
From a design point of view, I'd prefer the decoding functions in a separate source file, that way, new decoders may be added easily and decoding complexity gets out of the cache part (the decoding internal state moves from the Cache entry to the decoding module, and decoding functions can be reused or extended). If we think of decoding as one part in a pipeline, null-decoding is what we have now, and gzip-decoding what we'd make for gzip. That way we can keep only one path for the data stream, and null-decode or gzip-decode into 'Data' when we need it. This solves the problem of using 'Data' while decoding naturally, because it is perceived as it always was (new-bytes from a stream), the only difference being they now come pushed from a decoder instead of the net (quite transparent).
Good: 1. Faster!
2. Faster!
Yes. I can't wait to try it under a telephone line modem next week. :-) BTW, do you plan to make the linkblock/callback patch for html.cc (analog to plain.cc) or do you prefer me to work on it? -- Cheers Jorge.-