Clarification. I forgot to describe what I mean with "meta data inheritance". It's far from obvious.
Some meta data elements can be placed under either <files> or <file> right now. If there is such an element under <files> and one or more files miss the same element, then they "inherit" the value from <files>. See the ID for details. This is what I mean with "meta data inheritance". Hampus Hampus Wessman wrote, 2009-08-04 15:38: > 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. > > 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. > > > 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. > > > 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). > > > 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> > > > That was a far too long e-mail... Kudos to everyone that got this far! > > Keep up the good work with the internet draft, Anthony. > > Hampus --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
