On Thu, May 6, 2010 at 1:06 PM, petero <[email protected]> wrote: > In our particular application we already serve files divided into > sequential pieces, each with their own hash (and an overall hash). The > files are also mirrored. > > It would be good to support an open standard - this would map onto > metalink, and pieces with a list of hash piece elements nicely. > > Except that our pieces are not the same size as each other. The piece > boundaries are based on content, rather than on a fixed size. It would > be possible, but inefficient, for the server to recalculate hashes > based on fixed size blocks. (Cryptographic hashes can't be > mathematically derived from hashes of smaller pieces therefore all the > content would have to be re-hashed.) Therefore: > > What are the thoughts on adding an optional attribute to the hash > element so that each piece can express its own length?
hi Peter, I had thought something like this would be nice for things like music, where if you edit the ID3 tags of an mp3, changing the artist or song, you change the whole file's checksum, while not really changing the important data at all. I don't think anyone else has mentioned it tho, so it sounds like a good candidate for an extension. hopefully, within the week, we should have RFC 5854 describing metalink. until then, there is this section on extending metalink which will not change: http://tools.ietf.org/html/draft-bryan-metalink#section-5 -- (( 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.
