On Fri, Jul 3, 2009 at 4:52 PM, Peter Poeml<[email protected]> wrote:
> On Fri, Jul 03, 2009 at 04:27:53PM -0400, Ant Bryan wrote:
>>
>> (a) <metadata> name
>> no one has a better name for URIs to torrents/metalinks? :)
>
> Things I thought of were
> "metaurl"
> "alternative location"
> "other description"
> "p2p"
I like "metaurl". anyone else have a preference?
>> (b) <verification> info does not apply to <metadata> files (torrents,
>> metalinks) but to the files the metadata points to.
>
> It *might* actually be used to verify content downloaded from the
> referenced location. And thinking about it, it should have precedence
> over verification metadata from the torrent, IMO.
that's what I think too. if you're downloading from a torrent, it's
own verification info is authoritative. if you've got a metalink with
verification info that also lists a torrent, I think the metalink's
verification info has to be authoritative and the torrent has to be
discarded if they don't match.
>> (c) need to add a file attribute to <metadata> so you can specify one
>> file from a multi-file torrent or metalink. (see Matt's discussion,
>> did we resolve this?)
>
> I for one don't see particular value in multi-file torrents, but I see
> the issue - I haven't a solution at hand though...
multi-file torrents are in use. if metalink clients want to be able to
take advantage of them, we need to figure something out :)
>> (d) <type> name
>>
>> I think <type> could be interesting/useful. but I think we need a more
>> descriptive name, like <dynamic> or...any ideas?
>>
>> 4.2.16. The "metalink:type" Element
>>
>> The "metalink:type" element is a Text construct that describes
>> whether the IRI from "metalink:origin" in a Metalink will contain
>> dynamic updated Metalinks or static content that is not updated.
>>
>> metalinkType =
>> element metalink:type {
>> "static" | "dynamic"
>> }
>
> Thinking about this, the practical relevance of the field at all might
> be marginal. A validity of a metalink could as well be specified by
> using existing HTTP semantics (Expires, Last-Modified, ETag,
> Cache-control headers, and such) which would also allow finder control.
I'm thinking about cases when you're getting the metalink from a
secondary source (not the origin) or not over HTTP, like being emailed
a metalink from a friend, from a FTP site, from a metalink search
engine/indexing site, or finding it on your hard drive. :)
say you find a metalink for an openSUSE ISO 3 years after it came out,
and you still want this old version for historical reasons or to use
on an old computer. you want that exact file, but maybe most mirrors
don't carry it anymore, or maybe the URLs used a naming like "latest"
instead of something unique that wouldn't change, or maybe the mirror
directories have all been renamed, etc. a metalink client could
request an updated metalink from the <origin>. I guess this is pretty
marginal but...
>> (e) where a metalink is static or dynamic, it will be nice to have
>> <origin> to know where it came from, if you're finding the metalink
>> from some other site. so I need to change or removed the following
>> text:
>>
>> o If metalink:type is "dynamic", metalink:metalink elements MAY
>> contain exactly one metalink:origin element.
>
> Would it be practical to just always specify the origin?
(typo, I meant "whether a metalink is static or dynamic...")
I think so.
If Metalink Documents are published, they SHOULD include an origin element.
?
>> (f) generator has a name, URI, and version.
>>
>> this whole section is borrowed from atom, I wonder how much it's used
>> in atom & if it helps? we currently can include a generator name. is a
>> URI and version really necessary for figuring out if a generator is
>> spurting out bad metalinks? isn't <origin> a better way to track down
>> an offender?
>
> I think that origin and generator are orthogonal - the origin is
> valuable to know in itself (and probably more so), but the used
> generator is also useful. Mainly for informational and debugging
> purposes. An URI wouldn't be necessary, I think that recommending
> something like HTTP User-agent (should give name of generator and
> version) would be sufficient, in a single field.
>
> (I always liked the HTTP spec for the User-agent - it recommends to put
> more significant things in the front of the string, and the less
> significant things at the end, which makes kind of sense)
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43
that's what I'm thinking, something like:
<generator>MirrorBrain/2.8.1</generator>
?
--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Metalink Discussion" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/metalink-discussion?hl=en
-~----------~----~----~----~------~----~------~--~---
