On Sat, Jul 4, 2009 at 5:10 AM, Hampus Wessman<[email protected]> wrote: > Anthony Bryan skrev: > > (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...
I do think it has potential, but maybe it'll never be realized. after 3+ years of no use, maybe it's time to trim this fat/cruft. anyone else want to weigh in? -- (( 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 -~----------~----~----~----~------~----~------~--~---
