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

[Yousong Zhou]

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.

                yousong

> This was the main purpose of the 1st patch.
>
>
> On 1 April 2014 03:20, Yousong Zhou <address@hidden> wrote:
>>
>> Hi, Jure.
>>
>> On 1 April 2014 03:46, Jure Grabnar <address@hidden> wrote:
>> > Hello,
>> >
>> > thanks for your feedback! I corrected the first patch.
>>
>> Then the 1st one is fine with me.
>>
>> I am not fluent with Metalink and libmetalink on how it handles the
>> type attribute.  In version 4.0 of the standard, there is no type
>> attribute for metalink:url element, only metalink:metaurl has it.
>> Though not explicitly using a word like "must" in version 3.0 of the
>> spec, looks like type attribute is a required one there (See 4.1.2.4
>> of the 3.0 spec).
>
>
> I thought so too, but if you take a look at 4.1.2.5 section of the v3.0
> spec, the last example shows that "type" attribute can be omitted.
>
>>
>> If that is the case, then the metalink file is not a
>> standard-compliant one if that attribute is missing.  Maybe later
>> people want a way to ignore those non-compliant metalink:url element.
>> But let that be another story when the need actually came up.  :)
>
>
> Then libmetalink should be tweaked a bit, to allow non-compliant <url>
> elements, because currently it just ignores them (v3.0).
> Although, to be honest, they could just switch to v4.0, where "type" is
> optional and properly parsed by libmetalink. :)
>
> Regards,
>
> Jure Grabnar
>
>