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

[Jure Grabnar]

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.
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