On Dec 08, 2003, at 14:23, ext Sandro Hawke wrote: > >>> So what if the feed must be be accessed over HTTPS? Do we then also >>> need a "feeds" scheme? >> >> This is why the new-URI approach seems to go against the grain >> of the current web architecture. >> >> What is needed here is pretty simple. The browser needs to be >> extended so that it recognizes two (or more) kinds of integration >> with helper applications, given a particular MIME type: >> >> 1. pass the content of the response to the helper application >> 2. pass the entire reponse, headers and all, to the helper application >> >> For #2, it could insert the original request URI into the response >> header, in case the helper application prefers that to the URI >> denoting the response. >> >> In either case, no need to get entagled with http vs https, etc. >> >> I.e., as Norman suggested, just make the browser and handler >> "do the right thing". No need for new URI schemes or handling >> semantics here. > > Just make the server include all the necessary information > (subscription instructions) in the response body. It seems to me, > looking at the semantics of the situation, that's the right thing to > do anyway. Yes. Having the necessary information in the RSS instance itself would be the simplest -- though a more general solution to MIME based delegation that included the ability to provide the full response (and request URI) to the helper app would probably have general utility. > > No need to hack the browser at all. > > (Although I still think doing this kind of thing from an aggregator > makes more sense, anyway.) > Well, I think the bottom line is that there are numerous ways to achieve the stated goals without having to introduce a new URI scheme. Cheers, Patrick > -- sandro > > -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.comReceived on Monday, 8 December 2003 07:32:28 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 September 2007 13:52:50 GMT