Hi Peter, I want to reiterate that I am not suggesting replacing the content of a Metalink document with a set of links. Just the opposite. I think Metalink is a perfect example of a resource descriptor with very specific use cases (as opposed to more generic descriptors such as POWDER and XRD). I am also not objecting to the use of content negotiation. It is your prerogative to define Metalink as a valid representation of a file resource. Either way, this is more of a philosophical discussion than a technical one and I think we are past that.
What I am suggesting is that links can offer similar functionality. <LINK> elements are not valid in this case because the HTML page is not likely to be the file being downloaded (unless you consider the HTML page another representation of the same resource, but that is a stretch in this case). This leaves us with HTTP Link headers, which can be obtained from a HEAD request on the file URI, and Link-Pattern records in the site's /host-meta file. The last option is interesting because it allows an entire download server to declare how to obtain a Metalink for any file within its authority (host). Yes, if you only download one file, you need two round trips. But if you are downloading multiple files from the same server, you can cache the /host-meta information and go directly to the Metalink descriptor for any given download. One more think that links can offer you is the ability to support Metalink of shared hosting environments where the service is not likely to give you access to content negotiation configuration on the server. But if you can drop a /host-meta file, you can bypass that and still support Metalink. But this of course requires that the spec tells client to look for such links if the Accept header approach fails. Now, the design requirements for the link framework I'm proposing are much more restrictive than what I am assuming you are using for Metalink. For example: 1. Clients can be assumed to have full access to the full HTTP feature set including content negotiation. 2. There is no such thing as a Metalink of a Metalink file (i.e. second derivative). 3. Metalink is not useful as a format for anything else. It is always associated with a file which is the primary focus. 4. File servers are willing to support content negotiation for file downloads. None of these are possible for my own use cases. For example, Yahoo! will not allow using content negotiation on key properties such as the front page, but I still need to associate a descriptor to it. Yes, it is unlikely that Y!'s front page will even support or benefit from Metalink. Also, many of the platforms I need to support such as Javascript, Flash, and old versions of PHP will not allow easy access to clients to some HTTP features. And many hosting services will not allow users to setup content negotiation for their files. So my suggestion is for you to keep what you have, and consider if the value of what I am proposing is worth including as a secondary discovery mechanism. EHL > From: [email protected] [mailto:metalink- > [email protected]] On Behalf Of Peter Poeml > Sent: Tuesday, February 17, 2009 5:02 PM > To: [email protected] > Subject: Re: Transparent Metalinks? > > > Hi Eran, > > On Tue, Feb 17, 2009 at 03:52:19PM -0800, Eran Hammer-Lahav wrote: > > > > To get past the "web theory" debate on conflating a resource and its > > metadata into one URI, all you have to do is make a case for Metalink > > to be a defined as a representation of the resource and not an > > external descriptor of it. Do that and you are aligned with most > > people in this space. The idea that Metalink is nothing more than an > > extremely degraded representation of the file itself is reasonable > (to > > me). > > > > The right solution here is to support both link-based discovery and > > content negotiation. This gives you full coverage of both client and > > server capabilities, and allows for optimizations. Links can tell a > > client that the site supports Metalink in the first place. Remember > > that most sites will not support it and links are a great way to > > declare that. > > > > Also, I can envision many cases where the end-user uses a browser to > > find its way to a page about a download. Since the browser already > got > > that HTML page, it can look for either Link header or element and if > > present, show a special UI for the user to get a better download > > experience (maybe turn the download button into a multi-choice menu). > > > > In addition, /host-meta (the third method described in my discovery > > proposal) gives an entire site the ability to declare support for > > Metalinks and a way to map from the file URI to the Metalink > > information. > > > > So I guess my question is, why not support both links and content > > negotiation? > > > > EHL > > Thank you very much for your educated and detailed thoughts. > > Thanks also for being present here on this list; I have subscribed to > the ietf-http-wg list to get a better interconnection by being present > there myself. Also to learn. > > I have a bit difficulty seeing the use case for the Link header right > now (although I'm fully supportive of it as another option), because in > my case (metalink generator running on download server), any HTML page > that the user might be looking at with a browser is typically running > on > a different server -- often even outside of my control -- which doesn't > support Metalinks itself. I have not digged deeply enough into the Link > header matter to fully understand it, but this seems like a intricacy > to > me. > > In addition, the fact that the metalink is transparently negotiated > allows for two further particularities -- one not unimportant, the > other > crucial: > 1) efficiency: for a small resource, let's say 512 bytes in size, it > would be inefficient to construct a metalink for it, or > even HTTP redirect the request, because to return the > resource directly results in about the same amount of > data being transferred to the client as the metalink or > HTTP redirect. The server response might even fit into > a > single TCP payload together with the headers. > 2) security: the server can decide to return certain resources > directly for security reasons. > > There can also be exceptions of other kinds; e.g. one part of the URL > space, or objects of a certain mime type, or objects matching a certain > file pattern, being redirected (HTTP 30x + Location header) to another > server, the latter not being metalink capable. > All these examples are not made up -- I could show you real Apache > config files. :) > > This makes it look unfeasible to me to declare metalink capability > globally. Of course, the server could maybe, eventually, do a metalink > for all the resources; but for a HEAD request or to generate a Link > header it would have to run through the full request processing phase > to > decide on it. > > All in all, the Link header seems to me to be more suitable for related > (other) resources. For instance, I can see a usecase for adding a Link > header, for foobar, to a foobar.md5 and foobar.asc and foobar.sha1 and > foobar.torrent resource. From there it would be a logical step to say > that foobar.metalink would also be such a resource - yes. However, how > many Link headers can I practically add without exceeding the size of a > single TCP packet? It would not be practical as far as I can see. It > makes sense only in selected cases I think. On the contrary, a Metalink > already _is_ a "directory" of such related resources in a way which > encompasses them together in a format that can be handled in an > efficient way. Like a hundred Link headers at a time ;) Looks like a > similar effort, doesn't it? ;) > > I'm new to this, and happy to learn more. > > Thanks, > Peter > -- > Contact: [email protected] (a.k.a. [email protected]) > #opensuse-mirrors on freenode.net > Info: http://en.opensuse.org/Mirror_Infrastructure > > SUSE LINUX Products GmbH > Research & Development --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
