I would like to add that I don't think that the amount of software out there already supporting this version is a large problem[1].
I agree that we should ready ourselves for the future and I must admit that I have not thought about the metalink format getting a revision or second version. Although I agree we should ready ourselves, I think it is still possible to call new version the "first and most-final-of-all" versions. There is the problem of the distribution at download.o.o, and I don't want to endanger. Maybe it is possible to get the Aria2 to include a version string in their user agent in the upcoming version? (currently it's "aria2", maybe "aria2/version" would be good) If you add the elements both inside and outside of the container, aria2c will still run ok. I've tried this with putting URL elements outside of the resources, and that worked just fine. The removal is something where Anthony shows his commitment to perfection and I think it's something that we should certainly try to support. I'd be happy to try out new things and think about solutions if this change may cause a problem. You can also contact me personally if you think I may be able to think around a problem. Greets, Bram [1] Re-programming the interpretation of a file format is trivial. As far as I know, there has not been a single program which has been programmed around this file format, there is simply a programming structure where the information was able to hook into. On Fri, 2009-08-21 at 18:03 -0400, Anthony Bryan wrote: > 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 -~----------~----~----~----~------~----~------~--~---
