On 4 Aug., 15:38, Hampus Wessman <[email protected]> wrote: > Hello everyone! > > This is not a review of the internet draft document as such, but rather > some more general changes to the structure of the format that I think > would make metalinks a lot easier to use in computer programs The > changes should be fairly easy to add to the ID if Anthony and the rest > of you like them. Sorry for suggesting all these changes at this late > stage, but I think they are important so please take a look at them at > least. > > My suggestions would make the new format backwards incompatible, but > AFAIK the ID isn't completely compatible with most current > implementations anyway (not meta data at least). I think it is more > important to make the standard as good as possible than making it > backwards compatible. Clients with support for 3.0 will be able to add > support for the new standard easily anyway. >
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. > Here's my suggested changes: > > Change 1: Remove unnecessary tags that carry no information > > The metalink format contains some tags that could be removed without > losing ANY functionality. I'm thinking about <files>, <verification> and > <resources>. They may look pretty to humans, but I think the format > would be easier to deal with if they were removed. A metalink contains > one or more files, which contains hashes and urls (among other things). > The following xml structure reflects this hierarchy just as well as the > current one: > > <metalink> > <file name="example.ext"> > <identity>Example</identity> > <hash type="md5">2156346474343745</hash> > <url>http://example.com/</url> > <url>ftp://ftp.example.com/</url> > </file> > <file name="example2.ext"> > ... > </file> > </metalink> > > (I skipped some details here, like <?xml ...) > > In my experience it would be easier to parse/load/read a metalink with > that structure. It may depend on how you do that, but I can't think of > any situation when it would make it harder. I'm all in favor of it. I guess most applications fully ignore those extra structure anyway and do something like getElementsByTagName ('file') or xpath('//file') or handleElement(element == 'file') or whatever their xml library provides. So I don't think this will be a hard-to-implement change for most applications, and it might be easier to do for new ones. > > Change 2: remove "piece" attribute from piece hashes > > The internet draft does state that the "piece" attribute starts at zero > and "increses", which probably means that you must supply the chunk > checksums / piece hashes in the right order (the first one first and so > on). This is really good. Otherwise you need to sort them each time you > load a metalink file. > > If you supply the piece hashes in the correct order, then you don't need > the "piece" attribute as the order of xml elements is significant (you > can't, for example, show the <p> tags in an xhtml document in any > order!). Having the piece attribute will without doubt make people > believe you can supply them in any order, as that is the only reason for > having it. > > My suggestion: remove the "piece" attribute and require that the piece > hashes are placed in the correct order. Sounds reasonable and feasible, too. > Change 3: Remove (and forget about!) meta data inheritance > > This is a confusing and unnecessary part of the standard, which makes it > harder for applications to read metalinks and only gives us some kind of > "compression" in return (i.e. some duplicates of tags can be removed in > multi-file metalinks, at times). If we really want small files, then an > XML-format is the wrong way to achieve that. In that case we should > investigate alternative solutions, because there will be better ones. > > Even though this feature might be useful in some situations, I think the > added complexity it adds to every application that wants to load a > metalink is a too high price to pay. It is far more important that > metalinks are easy to deal with (and easy to understand!) than that they > are as small as possible. Remember, XML isn't small and will never be! > Lets focus on what we are good at instead (ie being a nice and easy xml > format that bundles data about files). This indeed is unnecessarily complex. I say: drop meta data inheritance. > Change 4: Add meta data about the metalink (i.e. about the whole > metalink as such) > > Screenshot of DTA:http://hampuswessman.se/dta_metalink.png > > A metalink contains a collection of files. The current standard only > makes it possible to add meta data (ie identity, description, ...) for > each separate file. Many clients display information about the > collection as such (i.e. the whole metalink). See the DTA screenshot > above for an example. These clients apparently interpret the contents of > the metalink wrong as there is no such data in the metalink format. The > "meta data inheritance" mentioned in Change 3 is probably one reason for > this confusion. > > Now to the solution. I like the way that e.g. DTA presents the metalink > and so I think we should adapt the format after this. More precisely, we > remove all kinds of "meta data inheritance" (see change 3) and then we > add some new tags directly under <metalink>, like <identity> and > <description>. Exactly which can be determined later on. This way there > would be some meta data about the <metalink> and some about each <file> > and it would be placed directly under those tags (only). > > This would make the metalink format behave more like many people who > come into contact with it for the first time expects it to work (in my > very limited experience). It would also be very useful. An example is a > good way to describe why: > > A web site presents their 10 favorite open source games in an article. > They want everyone to be able to download these games easily. A metalink > would, of course, be perfect! They add all the 10 games to the metalink > and write short descriptions (and so on) for each file/game. They also > set the <identity> of the metalink (ie of the whole collection of files) > to "Our 10 favorite games" and add a description to the whole metalink > which describes what kind of file collection this is. > > When using DTA to download this fictional metalink, we would be > presented with the description of the metalink at the top and then each > file below. We can then choose which files we actually want and so on... > Perfect!! > > Example xml: > <metalink> > <identity>The best 10 open source games ever</identity> > <description>...</description> > > <file name="wesnoth.exe"> > <identity>Wesnoth</identity> > ... > </file> > > <file name="superpong.exe"> > <identity>Super Pong 3000</identity> > ... > </file> > ... > </metalink> As you noted DTA already does this. So I guess it's clear where I stand ;) To sum it up: I'm in favor of all 4 change proposals. Cheers Nils --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
