ID-11: Removed metadata inheritance and most other elements from files element.
"piece" attribute removed in svn. please review & provide comments. On Aug 8, 12:17 pm, Hampus Wessman <[email protected]> wrote: > Tatsuhiro skrev, Den 2009-08-08 17:13: > > > On Aug 6, 7:59 am, Anthony Bryan <[email protected]> wrote: > > >> On Wed, Aug 5, 2009 at 10:13 AM, Tatsuhiro<[email protected]> wrote: > > >>> On Aug 5, 3:24 pm, Anthony Bryan <[email protected]> wrote: > > >>>> On Tue, Aug 4, 2009 at 9:38 AM, 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. > > >>>> it's not too late by any means, thanks for taking the time Hampus! > > >>>>> 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. > > >>>> it's been my intention to keep the ID version as close to the current > >>>> version as possible (at least for assisting downloads), until it MUST > >>>> not be. > > >>>> this is because the ID is a re-specification of something we have a > >>>> few years experience with, and 50+ programs that currently support it. > >>>> at my last count, 9 of those were closed source & will be slow to > >>>> update. most of the open source clients will probably be slow to > >>>> update, even in the current "search & replace" version. > > >>>> I've been trying to balance an attempt at (almost) perfect and > >>>> backwards compatible. I've tried to slim things down & make them > >>>> simpler. > > >>>> now is the perfect time for change! > > >>>> how bad are things currently? & how much better will we make them with > >>>> changes? what will be the incentive for authors to do more work? > > >>>> also, it's probably a good time to discuss what to do in the > >>>> changeover period to convert back & forth between versions. a python > >>>> script, .exe for windows users, XSLT, a web service... > > >>>> these are some great suggestions! > > >>>> why don't we take them on, starting with less invasive first. that > >>>> would be #3, 4, 2, then 1 I think. > > >>> I like the idea 'Change 2: remove "piece" attribute from piece > >>> hashes'. > >>> Actually aria2 sorts piece hash data by its index! > > >>> I think the current ID is very well written in terms of compatibility > >>> and improvements Anthony mentioned, but hey, I don't say there are no > >>> room for change ;) > > >> thanks! > > >> can you (plural :) suggest new text for the hash element in the ID? > > > OK, my idea is as follows. > > > At the end of 4.1.6. The "metalink:pieces" Element, the following > > statement is added to tell readers that metalin:hash must be ordered > > from index 0 to the last: > > > * metalink:hash elements MUST be ordered from the beginning of a > > file to the end. > > > I'm not confident about the "ordered from the beginning..." > > part. Could you suggest more clear text? > > Perhaps the paragraph under 4.1.6 could be changed into: > The "metalink:pieces" element contains a list of checksums for > non-overlapping pieces of the file. The checksums MUST be listed in the > same order as the corresponding pieces appear in the file, starting at > the beginning of the file. 4.1.6. The "metalink:pieces" Element The "metalink:pieces" element acts as a container for a list of checksums of non-overlapping pieces of the file. The checksums MUST be listed in the same order as the corresponding pieces appear in the file, starting at the beginning of the file. > I also think 4.1.6.2 should be changed to (note: changed piece to pieces > on the second line) > metalink:pieces elements MUST have a "length" attribute, which is an > integer that describes the length of the pieces of the file in octets. > The whole file is divided into non-overlapping pieces of this length, > starting from the beginning of the file. The last piece extends at most > to the end of the file and can therefore be shorter than the other pieces. > > This would explain more in detail what parts of the file that the pieces > describe. sounds great! 4.1.6.2. The "length" Attribute metalink:pieces elements MUST have a "length" attribute, which is an integer that describes the length of the pieces of the file in octets. The whole file is divided into non-overlapping pieces of this length, starting from the beginning of the file. The last piece extends at most to the end of the file and can therefore be shorter than the other pieces. > > And also, in 4.2.5. The "metalink:hash" Element, I suggest following > > text: > > > The "metalink:hash" element is a Text construct that conveys a hash > > for a file. All hashes are encoded in lowercase hexadecimal > > format. metalink:hash elements MUST have a "type" attribute if and > > only if it contains a hash of a complete file. > > > metalinkHash = > > element metalink:hash { > > attribute type { text }?, > > text > > } > > > And change the 2nd example like this: > > > Metalinks can also contain hashes for individual pieces of a file. > > metalink:hash elements contain a hash for > > that specific piece or chunk of the file, and are of the same hash > > type as the metalink:pieces element they are contained in. > > > ... > > <verification> > > <hash type="sha-1">a97fcf6ba9358f8a6f62beee4421863d3e52b080</ > > hash> > > <hash type="sha-256">fc87941af7fd7f03e53b34af393f4c14923d74 > > 825f51116ff591336af4880227</hash> > > <pieces length="1048576" type="sha-1"> > > <hash>d96b9a4b92a899c2099b7b31bddb5ca423bb9b30</hash> > > <hash>10d68f4b1119014c123da2a0a6baf5c8a6d5ba1e</hash> > > <hash>3e84219096435c34e092b17b70a011771c52d87a</hash> > > <hash>67183e4c3ab892d3ebe8326b7d79eb62d077f487</hash> > > </pieces> > > </verification> > > ... > > > And 4.2.5.2. The "piece" Attribute will be removed. > > I really like all those suggestions! 4.2.5. The "metalink:hash" Element The "metalink:hash" element is a Text construct that conveys a hash for a file. All hashes are encoded in lowercase hexadecimal format. metalinkHash = element metalink:hash { attribute type { text }?, text } Metalinks can contain one or multiples hashes of a complete file, for example both SHA-1 and SHA-256. metalink:hash elements with a "type" attribute MUST contain a hash of the complete file. ... <verification> <hash type="sha-1">a97fcf6ba9358f8a6f62beee4421863d3e52b080</ hash> <hash type="sha-256">fc87941af7fd7f03e53b34af393f4c14923d74 825f51116ff591336af4880227</hash> </verification> ... Metalinks can also contain hashes for individual pieces of a file. metalink:hash elements that are inside a metalink:pieces container element have a hash for that specific piece or chunk of the file, and are of the same hash type as the metalink:pieces element they are contained in. metalink:hash elements without a "type" attribute MUST contain a hash for that specific piece or chunk of the file and MUST be listed in the same order as the corresponding pieces appear in the file, starting at the beginning of the file. ... <verification> <hash type="sha-1">a97fcf6ba9358f8a6f62beee4421863d3e52b080</ hash> <hash type="sha-256">fc87941af7fd7f03e53b34af393f4c14923d74 825f51116ff591336af4880227</hash> <pieces length="1048576" type="sha-1"> <hash>d96b9a4b92a899c2099b7b31bddb5ca423bb9b30</hash> <hash>10d68f4b1119014c123da2a0a6baf5c8a6d5ba1e</hash> <hash>3e84219096435c34e092b17b70a011771c52d87a</hash> <hash>67183e4c3ab892d3ebe8326b7d79eb62d077f487</hash> </pieces> </verification> ... 4.2.5.1. The "type" Attribute metalink:hash elements MUST have a "type" attribute, if and only if it contains a hash of the complete file. The IANA registry named "Hash Function Textual Names" defines values for hash types. If a Metalink Document contains verification information, it SHOULD include "sha-1" which is SHA1 (or stronger), as specified in [RFC3174]. It MAY also include other verification algorithms. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
