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.
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.
> 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!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
