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?
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.
>
>
> >> so for #3, you suggest we remove metadata inheritance & these elements
> >> from <files>:
> >> copyright
> >> description
> >> identity
> >> language
> >> license
> >> logo
> >> os
> >> publisher
> >> version
>
> >> that makes things quite a bit simpler...
>
> > I agree to change#3. Metadata inheritance is too complicated for its
> > own good.
> > I think metalink file is generally produced by machine, not human, it
> > can copy all metadata to all file without complain and we should not
> > care about the size of XML. If size matters, we can use gzip to
> > transfer compressed file.
>
> ok, metadata inheritance is out!
>
> check svn for newest version :)
>
> --
> (( 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
-~----------~----~----~----~------~----~------~--~---
