bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget


From: Yousong Zhou
Subject: Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget
Date: Wed, 2 Apr 2014 10:00:23 +0800

Hi,

On 1 April 2014 23:02, Jure Grabnar <address@hidden> wrote:
>
> On 1 April 2014 10:39, Yousong Zhou <address@hidden> wrote:
>>
>> On 1 April 2014 15:48, Jure Grabnar <address@hidden> wrote:
>> > Hi,
>> >
>> > I debugged code before writing the 1st patch and found out that if
>> > "type"
>> > attribute is not present in v3.0, libmetalink completly ignores it (URL
>> > is
>> > not present in resources!).
>> > If you write "type" attribute in v4.0, libmetalink ignores it (only
>> > "type",
>> > URL is still present in resources!). So you have to find out protocol
>> > type
>> > from URL in v4.0.
>>
>> But the type attribute is currently not used by wget.  I cannot find
>> any reference to it outside metalink.c.  Anyway, IIUC, types like
>> torrent, ed2k, etc. are not in the realm of wget.
>

I just checked 4.1.2.5 of metalink 3.0 spec.  It says when the "type"
attribute is missing users can derive if it is for BitTorrent by
examining the suffix of the URL.  That's bad.  URL is only for
Universal Resource Locator, it doesn't end with a specific name to
indicate its type.  I may say that libmetalink does the right thing by
ignoring those metalink:url element.

>
> That's true. "type" is currently only used to filter out types which Wget
> doesn't support.
> Do you think parsing it ("type") is irrelevant?

IMHO, if it will not be used in the near future, then better document
or remove it.

>
> Regards,
>
> Jure Grabnar
>



reply via email to

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