On Jan 17, 8:10 pm, Eran Hammer-Lahav <[email protected]> wrote: > On Jan 17, 6:09 am, Nils <[email protected]> wrote: > > > In my opinion Metalinks are a representation of the actual resource > > BECAUSE they are a description of something that actually exists, and > > are not merely a link/pointer/reference. > > Hence TCN is correctly used here. > > And hence there is no problem at all. > > This is a bit of a contradiction. Something cannot be a > representation of a resource and a description of it at the same time. > But of course people can (and have) stretched the meaning of > 'representation' to be, well, pretty much anything.
A metalink is a representation of a resource, like a JPEG is a representation. metalinks may be far more "degraded" and contain pointers to better version. A description is always also a representation of the resource, it usually is just (heavily) degraded. (My philosophical view) > > And I think a philosophical discussion of "representation vs. > > description vs. complete view" in general and of the intension the > > authors of 1997 and 1998 RFCs had in particular is non-sense. > > I am not sure how 1997/8 are related to this. I meant the years HTTP/1.1 and TCN where published receptively. Sorry for the misleading wording. > > > There is a valid point for Link:, e.g. for referencing previous > > chapters of a document or telling the client "hey, I have an > > alternative representation here you didn't think of requesting > > yourself you might still be interested in", i.e when you actually want > > to reference/point another resource. > > Link defines a relationship between any two resources. "My Metalink > description" is a valid relationship. > I agree. And it might be a good thing to have Link pointers for dumb clients. But Link doesn't fulfill the propose/use case of TCN as used by metalink. Futhermore it adds more load to the server as it has to (start to) serve the download in question. > > When it comes to metalink TCN, the client explicitly has to ask the > > server for this representation, and hence there is no problem for non- > > metalink clients receiving the fairly degraded (to them at least) > > metalink view. > > (Maybe this should be clarified in the Metalink spec, especially that > > servers should assign a pretty low q=3D-value to metalink > > representations of a resource to avoid sending out metalinks to non- > > metalink clients). > > Again, there is nothing 'technically' wrong with this approach any > others have taken a similar position that a descriptor can be > collapsed into a single resource URI. The TAG members argue that our doing basically violates the indent of the RFCs in question, which makes it technically wrong, no? > But a consensus is building that > this is the wrong way of doing things. Unless there is a right way (and like mentioned above Link doesn't fulfill the requirements (to reduce server load, especially number of requests)) such a consensus is useless. For avoiding any given "wrong way" there has to be a right way to start with. > What you might want to > consider, since you find the semantic discussion as nonsense (which I > can respect) is the deployment ramifications of using the Accept > header. Many platforms limit access to such headers. Such platforms likely limit everything else, too, like a potential Link header. > some proxies > mishandle Vary headers (which BTW, the spec should require with to any > Accept reply). So should we now abandon TCN altogether, even for the "blessed" use cases? > and some providers will not allow using it on their > servers. But there is a guarantee you may use Link headers? > You might want to read John Panzer's view of this [1]. The only "new" discussion point would be "Extendable - limited to a single content-type for metadata, and does not allow any existing schemas (with well known content-type)." TCN Accept allows to specify multiple types and even associate preference with those. For example, DownThemAll! currently sends an Accept like this (Firefox default + metalink): Accept: text/html,application/xhtml+xml,application/xml;q=3D0.9,*/ *;q=3D0.8, application/metalink+xml;q=3D0.9 I could imagine other headers like the following would do a great job too: Accept: */*;q=3D0.8, application/metalink+xml,application/x- bittorrent;q=3D0.9 Meaning: Return me a metalink or a torrent if you go some, else return me what you got instead. Other than this, he details some great ideas on how to overcome some potential issues. > > You can also support both approaches, allowing providers to accept the > Accept header, but also declare the availability of metalink using the > Link header. Dumb clients can then do a HEAD on the URI if they cannot > use Accpet. I'm all in favor to adding Link to metalink, but not replacing TCN, but instead additionally to it. I also read your overview about different discovery methods [2]. Great overview. TCN, however, still works best for the given use case, and except for some "philosophical" issues and implementation/deployment obstacles I don't see any show-stoppers there. > > EHL Cheers Nils > > [1]http://www.abstractioneer.org/2008/11/discovery-metadata-is-just- data... [2] http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html (Note: Resent after mistakenly sending only to Eran) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
