I was just messing around & needed to put it up because someone posted
what I was writing & I didn't want it to look like I was copying them.
here are some other shortcomings:
Appendix B. What's different...?! (to be removed by RFC Editor before
publication)
...or missing, compared to the Metalink XML format
[draft-bryan-metalink] :
o (+) Reuses existing standards without defining much new stuff.
It's more of a collection/coordinated feature set.
o (+) No XML dependency.
o (-?) Tied to HTTP, not as generic. FTP/P2P clients won't be
using it unless they also support HTTP, unlike Metalink XML.
o (---) Requires changes to server software.
o (-?) Could require some coordination of all mirror servers for
all features, which may be difficult or impossible unless you are
in control of all servers on the mirror network.
o (-) Metalink XML could be created by user (or server, but server
component/changes not required).
o (-) Also, Metalink XML files are easily mirrored on all servers.
Even if usage in that case is not as transparent, it still gives
access to users at all mirrors to all download information with no
changes needed to the server.
o (-) Not portable/archivable/emailable. Not as easy for search
engines to index?
o (-) No way to show mirror/p2p priority or geographical location
(yet).
o (---) No chunk checksums/download repair (yet).
o (-) No checksums besides MD5/SHA-1 (yet).
o (-) Not as rich metadata.
o (-) Not able to add multiple files to a download queue or create
directory structure.
http://tools.ietf.org/html/draft-bryan-metalinkhttp-00#appendix-B
On Fri, Aug 28, 2009 at 6:59 PM, Bram Neijt<[email protected]> wrote:
>
> Hi all,
>
> Personally, I don't believe in HTTP headers as mirror descriptors. One
> of the main reasons to use mirrors is to keep the load of the primary
> server down. If you want to keep the load down, then you should not
> send the whole file to every user you encounter, but to get the mirror
> list the user will have to hit the link. One way would be to only
> allow a HEAD request, but that seems idiotic to me because there is no
> way to make sure people would only use the head request.
>
> I've yet to come up with a problem this additional header complexity
> would solve.
>
> Bram
>
>
> On Fri, Aug 28, 2009 at 8:03 PM, Ant Bryan<[email protected]> wrote:
>>
>> here are my very rough ideas for Metalink in HTTP headers
>>
>> http://www.ietf.org/id/draft-bryan-metalinkhttp-00.txt
>>
>> briefly, it's:
>>
>> Link: <http://www2.example.com/example.ext>; rel="alternate";
>> Link: <ftp://ftp.example.com/example.ext>; rel="alternate";
>> Link: <http://example.com/example.ext.torrent>; rel="describedby";
>> type="torrent";
>> Link: <http://example.com/example.ext.asc>; rel="describedby";
>> type="application/pgp-signature";
>> Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=
>>
>> On Jul 28, 5:37 pm, Anthony Bryan <[email protected]> wrote:
>>> this is similar to some of metalink's features, but done in HTTP headers.
>>>
>>> ---------- Forwarded message ----------
>>> From: Henrik Nordstrom <[email protected]>
>>> Date: Mon, Jul 27, 2009 at 11:03 AM
>>> Subject: Re: HTTP Extensions for Simultaneous Download from Multiple Mirrors
>>> To: HTTP Working Group <[email protected]>
>>>
>>> This draft made a bit of surprise appearance in the transport area
>>> meeting today:
>>>
>>> http://tools.ietf.org/html/draft-ford-http-multi-server
>>>
>>> My initial reaction is lots of obvious overlap with other work and
>>> misunderstandings of basic HTTP functions like ETag.
>>>
>>> Basic motivation behind the work may be reasonable however.
>>>
>>> I will try to catch the author for a more in-depth discussion shortly.
>>>
>>> Other opinions?
>>>
>>> Regards
>>> Henrik
>>>
>>> --
>>> (( Anthony Bryan ... Metalink [http://www.metalinker.org]
>>> )) Easier, More Reliable, Self Healing Downloads
>> >
>>
>
> >
>
--
(( 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
-~----------~----~----~----~------~----~------~--~---
