[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] IDN and IRI tests fail on MS-Windows with wget 1.16.1
From: |
Tim Ruehsen |
Subject: |
Re: [Bug-wget] IDN and IRI tests fail on MS-Windows with wget 1.16.1 |
Date: |
Mon, 29 Dec 2014 15:36:55 +0100 |
User-agent: |
KMail/4.14.2 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) |
On Saturday 27 December 2014 21:19:09 Eli Zaretskii wrote:
> > From: Tim Rühsen <address@hidden>
> > Cc: Eli Zaretskii <address@hidden>
> > Date: Sat, 27 Dec 2014 20:05:51 +0100
> >
> > After having a deeper look into IRI/IDN design of Wget I have to correct
> > myself. IMHO, Wget's IRI support seems to be deeply broken. I guess it
> > needs a redesign to fix it. And that exceeds the amount of time that I
> > have.
> Can you elaborate on your finding, including the problems in the
> design, please?
I did elaborate IRI/IDN and implemented it correctly (IMO) here:
https://github.com/rockdaboot/mget
It is basically about parsing/converting *any* URL into a 'normalized'
structure (knowing the charset encoding) and further only working with this.
The Wget code distinguishes between URI and IRI which is not needed. This
bloats the code, thus increases the needed resources for maintenance and
increases the number of issues.
Looking at the code also reveals the usage of static variables that introduce
side-effects when calling functions. When I fixed Test-idn-meta, another test
broke because of this fix. It was such a side effect. Also we have functions
being too long with huge loops and gotos. Touching the code likely breaks
things beyond imagination (and beyond the test suite, like this: ).
Adding multi-threading to the existing code (which is a declared goal since
many years) is IMO much more work than a rewrite (which I did in the Mget
project - and multi-threading was the easy part).
Now, i am a bit OT. But the above and several things more come together. To
sum up: IMO, Wget code is a fragile and hard-to-extend patchwork.
Tim
signature.asc
Description: This is a digitally signed message part.