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). 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". 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. After all, there is a lot of software out there implementing a status quo, which we don't want to throw away. 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? Peter -- Contact: [email protected] (a.k.a. [email protected]) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
pgpzL1Peb7KBL.pgp
Description: PGP signature
