On Fri, Aug 21, 2009 at 5:40 AM, Peter Poeml<[email protected]> wrote: > Hi, > > On Sat, Aug 15, 2009 at 05:19:18AM -0700, Nils wrote: >> On 4 Aug., 15:38, Hampus Wessman <[email protected]> wrote: > [lots of good suggestions] >> The ml3.0 and rfc draft are incompatible anyway. I'm all in favor of >> making the rfc as good as possible. The backwards-compatibility is >> already gone anyway, i.e. applications need to implement a new reader >> anyway. > > [...] > > > Interesting thread! I find all your suggestions very good and useful. > > > > The whole incompatibility starts to bother me, however. It's getting > more and more ;) (and maybe this is good, because it makes us think more > about compatibility issues).
yes, quite important to think about! > So far, we don't have a way to distinguish clients in terms of which > "level" they support. There is only one mime type, and we are > effectively defining a new format on the mime type that's already > (inofficially) in use. There is only one file ending, ".metalink". I changed the mime type (at least temporarily) in the latest svn: application/metalink4+xml is it hard to map two mime types to one file extension? it seems like that would at least make things unnecessarily complex. if we need a new file extension, I suggest ".meta4" in English, a metaphor: A figure of speech in which a word or phrase that ordinarily designates one thing is used to designate another One thing conceived as representing another; a symbol a figure of speech and or phrase that portrays one word as being or equal to a second object in some way. 1533, from M.Fr. metaphore, from L. metaphora, from Gk. metaphora "a transfer," especially of the sense of one word to a different word, lit. "a carrying over," from metapherein "transfer, carry over," from meta- "over, across" (see meta-) + pherein "to carry, bear" (the ID has a section for the mime type called Interoperability considerations). > At openSUSE, we will have a million of openSUSE installs soon, which > download metalinks with aria2c via transparent negotiation - > and I fear that there will be no way that I can upgrade > download.o.o to generate a new format, because the existing clients > wouldn't understand it. We cannot upgrade aria2c everywhere; > CD/DVD hardcopies can't be changed once they have been produced. > At the same time, I would like to start providing the new format on > download.opensuse.org as soon as possible. > > I could generate metalinks in more than one formats - that > wouldn't be a problem - but then I would need to know which client wants > which format. The clients would need to indicate somehow which format > they want. If they don't, the only sound assumption on the server side > would be: "give the client a classic metalink unless it explicitely asks > for (also) the new, IETF-blessed format". So we might need a new mime > type, if I don't overlook anything. in the future if we end up using that Link header, those could always be IETF format. > After all, there is a lot of software out there implementing a status > quo, which we don't want to throw away. VERY TRUE! > Most stupid question, is it possible somehow to write metalinks that > contain *both* formats? Is it possible to do this in a way that allows > existing clients to continue to understand the old format - while newer > client implementations would use the newer format? my first guess is that this would be a v3 metalink and ID metalink in the same file using the 2 different namespaces. v3 clients only read the v3 part of the file & ignore the rest ID clients only read ID part. v3/ID clients default to ID. -- (( 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 -~----------~----~----~----~------~----~------~--~---
