bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] FeatureSpecification - HTTP compression


From: Tim Ruehsen
Subject: Re: [Bug-wget] FeatureSpecification - HTTP compression
Date: Tue, 11 Dec 2012 17:12:09 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Am Monday 10 December 2012 schrieb Micah Cowan:
> On 12/09/2012 02:45 AM, Tim Rühsen wrote:
> > Am Samstag, 8. Dezember 2012 schrieb address@hidden:
> >> Hello
> >> 
> >> I think wget should HTTP compression (Accept-Encoding: gzip, deflate).
> >> It would put less strain on servers being downloading from, and use
> >> less of their bandwidth. Is it okay to add this idea to the
> >> http://wget.addictivecode.org/FeatureSpecifications page? I don't know
> >> where on the page to add it, and thought I should check first before
> >> doing so in case there was a reason it isn't there
> >> 
> >> Thank you for your time
> > 
> > The next Wget to come (still called Mget) already has this feature
> > working.
> 
> I don't think there's been agreement that the next Wget will be called
> Mget, or that the current work on Mget represents a step towards
> replacing Wget, so I think it's quite misleading to refer to Mget as
> "the next Wget to come".

Sorry, yes. It is a bit misleading.

> Current Wget sources already have concurrent
> downloading available, and many other features, both new and
> pre-existing, that are not featured in Mget.
> 
> Wget proper doesn't have gzip/deflate support currently, but it's not
> too hard to add it, and I wouldn't be surprised if it gets added in the
> near future; it just hasn't been as high a priority as other
> recently-introduced features had been, I believe.

Maybe there is a misunderstanding.
Due to our postings earlier this year, I am *NOT* working on new features 
(regarding Wget) right now. The current goal is to provide most Wget 
features/options to satisfy the Wget test suite. Just as a side effect, there 
are some new features in Mget, but not many.

While doing that "big refactoring" I moved lot's of functionality into a 
library form. As soon as I am done with Wget compatibility, I will create this 
libmget (+ docs & examples), which I will present here for discussion before 
it moves to libwget (or whatever we agree on). That we could merge 
Mget/Wget/libwget and/or even use the library to provide seperate tools.

Doesn't Niwt and Wget have some common code to use ? e.g. HTTP parsing / 
download / handling, HTML pasring, CSS parsing, Cookie handling and much more 
? Maybe we could agree on some common library code instead of having two ?

And after all, I appreciate any helping hands !

> 
> -mjc

Regards,

     Tim Rühsen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]