Anthony Bryan skrev: > 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? > I like that too. > >>> (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. > > I agree. It's the metalink you trust and it's what is described in there (including hashes) that you want... >>> (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 :) > We do =) >>> (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... > I'm not sure this is very useful. The creator may find more mirrors that could be added if you redownloaded the metalink, but I don't like the idea of auto-updating the metalink in the background. IMHO all metalinks should be static. Then you can inspect it (and its hashes) before starting the download and be sure that is what you get. I realize that it's possible to manually change it to static if you want, but at least I don't think the feature is important. It would be better to simplify the standard and remove this unused feature. One less thing for client developers to care about.
In situations like this I would prefer to instead have a URL to a web page where you can find out more about the metalink and download the latest version of the metalink (possibly for newer versions of the actual file(s) too). This way the user could visit the site about the metalink to check out what it is and download a newer version (if he/she wants to). Most of the time there will be no need to download newer versions, but this could be useful anyway. Perhaps there's already a field like this? (I might forget about something). In either case I think a field like this could be very useful! The idea would be, of course, that a client shows this url when you open a metalink and lets the user click on it to open a web browser... >>> (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> > ? > That looks good! I think doing it similarly to HTTP user-agent is both good and sufficient. We might be able to borrow a little from that spec then too =) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
