bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] wget2.0 / niwt / refactoring


From: Tim Ruehsen
Subject: Re: [Bug-wget] wget2.0 / niwt / refactoring
Date: Mon, 13 Aug 2012 12:47:13 +0200
User-agent: KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; )

Am Monday 13 August 2012 schrieb Daniel Stenberg:
> On Mon, 13 Aug 2012, Tim Ruehsen wrote:
> > But we should not forget about a monolithic, backward-compatibel (to wget
> > 1.x) wget 2.0. We all agree, it is time to redesign wget's code
> > architecture to have a clean codebase for new features to implement, to
> > increase readability/hackability, to increase modularity and to increase
> > code reusability (wget-derived libraries). Not to forget current C
> > language / library conventions and features like C99 and Posix
> > compatibility. On older systems wget 1.x would stay the preferred
> > version.
> 
> You should know I talk of my own project here, but I would like to remind
> people that when considering an overhaul of a (portable) HTTP/FTP project,
> there might be reasons to think about letting the transfers be handled by
> libcurl. It already supports more protocols, more SSL flavours and more
> features than the wget transfer engine and it exists as a completely free
> and open, proven and well documented library with a stable API today. Most
> of mget's "Not Yet Implemented" features are already supported by libcurl.
> 
> This said, I realize it is not kosher for a GNU project since libcurl is
> not GNU and I believe it will be a primary factor that will prevent this
> from happening. I still believe it would be smart from a technical
> perspecitive.

I like libcurl and use it in some closed-source projects.
I personally like GNU but i am not an GNU evangelist, so libcurl is an option 
for me. But then, a license discussion is OT right now, but we should come 
back to that in a later.

> Also, this is not a new idea and it has been turned down before:
>    http://daniel.haxx.se/blog/2007/10/27/wget-going-libcurl/ and
>    http://www.mail-archive.com/address@hidden/msg01129.html
> 
> BTW, would "older systems" include Microsoft Windows too then as you
> mention C99 which isn't supported by Microsoft compilers?

You don't have to use MS compilers on Windows. The gcc toolchain is available 
for MS Windows. Besides, MS Windows is definitely not a primary target (for me 
and GNU software).

> > Started as a just-for-fun coding, I just created a project 'mget' on
> > github. While working on it, I got the idea to merge it with wget 1.x
> > into wget 2.
> > 
> > Please have a look at https://github.com/rockdaboot/mget and let's start
> > a discussion, if that's what we want and how we should go on.
> 
> So this is basically a set of patches on top of the stock Wget? If it is,
> have those patches been posted here? If it isn't, how exactly does it
> relate to wget other than being a similar tool?

As mentioned above, wget 2 needs a rewrite (again, just my opinion). Mget has 
very fast  grown beyond a set of patches and already has features missing in 
wget. Mget could be the start of wget 2, if it becomes accepted by wget's 
developers and maintainers.

Regards, Tim



reply via email to

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