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

[Paul Wratt]

this is OT now, but the relavant information is in the first graph

""
at the moment if you try a recursive wget with --no-clobber
--convert-links the --no-clobber is discarded in favour of
--convert-links
""
that is:
wget --recursive --no-clobber --convert-links

that does break many examples on the net, along with a few other
because the defaults have changed. (I think one is the follow
redirects default - but dont quote me on that - maybe something to do
with Trusted)

the --convert-links is needed to make any mirror 100% locally
browsable. The --no-clobber is required because the mirror
periodically updated, and that mirror may contain a lot of very large
files that do not change.

------

The point is that any version from 1.13 on is not 100% gaurenteed to
function with or as described by any wget examples that were written
for any versions previous to that

This simple fact already causes me to think of any version after 1.13
as an unofficial wget v2.0x

So since we are already past the tipping point, the only relevant
question (for this thread) is to decide how best to get a v2 of the
ground.

On that point, although there has been some negative comment towards
using MGET as the base for v2, there would still have to be a code
review if it were used, so adopting it as a base for incremental
rewrites of current v1 codebase is well within practical
consideration. After all we are talking about reviewing a code rewrite
that has already been done (and is known to be functional, yes?). The
review will show up any "loss of functionality", in theory, proven
when run against the test suite.

The rest of the discussion I will leave to others for the time being.

Cheers

Paul


On Thu, Aug 16, 2012 at 8:19 PM, Tim Ruehsen <address@hidden> wrote:
> Am Thursday 16 August 2012 schrieb Paul Wratt:
>> just a note  (and observation)
>>
>> On Mon, Aug 13, 2012 at 9:01 PM, Tim Ruehsen <address@hidden> wrote:
>> > You can find millions of examples and references using the wget 1.x in
>> > the internet, in printed articles, etc. To not break all these examples,
>> > wget 2 should be backward compatibel with wget 1.x.
>>
>> the current wget v1.x already breaks compatibility with "millions of
>> examples and references using the wget 1.x". This goes as far back as
>> 1.13.
>
>> the options are still there, but some of the defaults are not, and in
>> some cases, certain combinations are no longer possible (as I have
>> mentioned before.. with no reply)
>
>> so at the current stand point v1.12 is the only version of wget that
>> can be used 100% reliably with "millions of examples and references
>> using the wget 1.x"
>>
>
> Your are talking about
> http://lists.gnu.org/archive/html/bug-wget/2011-11/msg00017.html
>
> From your post I really can't see a general "wget >=1.13 breaks millions of
> wget < 1.13 examples".
>
> You might help us (and yourself) by reducing your command line to the most
> simple case. How should we know (just from reading your post) if --restrict-
> file-names isn't the baddy ? Answer: We (maybe) have to test lots of
> combinations of your command options... something that you could have done.
>
> The simpler your case, the higher the chance of getting a response or someone
> writing a patch. This is absolute basic when reporting issues to anyone.
>
> Tim
>