- From: <Patrick.Stickler@nokia.com>
- Date: Fri, 6 Mar 2009 07:45:03 +0100
- To: <eran@hueniverse.com>, <jar@creativecommons.org>
- CC: <julian.reschke@gmx.de>, <connolly@w3.org>, <www-tag@w3.org>
On 2009-03-06 00:40, "ext Eran Hammer-Lahav" <eran@hueniverse.com> wrote: > I didnšt think you do. Your request *was* very clear... :-) > > Most web hosting services require a dedicated server to gain access to the > httpd configuration which is required to support custom methods. The > difference in cost between shared hosting and dedicated hosting is > significant. In addition, considering the OpenID use case (or any > bootstrapping of identity onto an existing web presence), we are talking about > existing blogging platforms from MySpace, to Facebook, to TypePad, etc. Most > of these allow adding HTML elements but not playing with any server > configuration required for custom methods (or Link headers). And therefore, to fully support linking as a uniform solution, since link headers are necessary for resources which do not allow reasonable embedding of links within representations (for various reasons), server environments *will* have to be changed to properly implement semantic web functionality, therefore the arguments that because URIQA requires changes to the server environment it is harder to deploy than link, because folks can embed links in their documents, etc. is invalid. If/when service providers, content producers, and/or consumers see the clear benefits to be obtained from semantic web technologies, web service and tool providers *will* implement what is necessary to effectively provide those benefits. Just because some proposed solution cannot be done *today* on someone's favorite blogging site, does *not* mean it is not the best solution in the long term. Such arguments are terribly short sighted. Patrick > > I just donšt have hard data to share... > > EHL > > > On 3/5/09 7:33 AM, "Jonathan Rees" <jar@creativecommons.org> wrote: > >> Eran, I am on your side. I have no particular plans to advocate for >> URIQA. We've exhausted the general argument. I'm just looking for >> particulars because I think they're interesting. If you don't want to >> offer any that's fine. >> >> I thought my request was very clear. I did not want to feed the flames. >> >> Jonathan >> >> On Mar 4, 2009, at 11:00 PM, Eran Hammer-Lahav wrote: >> >>>> The simple fact that most developers I work with have never heard of >>>> HTTP OPTIONS is enough of an indication for me that asking them to >>>> use MGET is not being practical. Yes, this argument doesn't fly with >>>> many people on this list, and I'm fine with agreeing to disagree. >>>> The idea behind my Link-based discovery proposal is that it offers >>>> three methods to accomplish the association of a descriptor to a >>>> resource. >>>> >>>> --- >>>> >>>> The decision whether URIQA and the M* methods are a good approach >>>> isn't really just a matter of figuring out if they can be hacked >>>> into most common httpd servers. >>>> >>>> If the URIQA authors are serious about getting adoption as a >>>> standard, they should submit it for a standards process as well as >>>> work with an organization like Apache to get it included in standard >>>> distributions. >>>> >>>> It seems to me that the IETF would be the appropriate venue given >>>> the fact this is an extension of the HTTP protocol. There are many >>>> real deployment issues with introducing a new HTTP method and real >>>> cost to the web. It is not my place to speculate on such >>>> ramifications because HTTP is not my area of expertise. >>>> >>>> I would love to see Nokia submit URIQA as an I-D for review by the >>>> HTTPbis working group. I am sure they can offer some valuable >>>> insight. If this was done in the past, I would love if someone could >>>> point me to it. >>>> >>>> Until URIQA is proposed as a standard (with some clarity regarding >>>> its licensing terms which I could not find other than a copyright >>>> statement at the bottom of the page), it would not be possible for >>>> me to treat it as anything but an interesting idea. And while at it, >>>> why not propose my own methods? Maybe LGET to get just the Link >>>> headers... >>>> >>>> The empirical data I would like to see is where is URIQA deployed, >>>> what's the scale of the deployment, what applications are using it, >>>> etc. >>>> >>>> EHL >>>> >>>>>> -----Original Message----- >>>>>> From: Jonathan Rees [mailto:jar@creativecommons.org] >>>>>> Sent: Wednesday, March 04, 2009 9:55 PM >>>>>> To: Eran Hammer-Lahav >>>>>> Cc: Patrick.Stickler@nokia.com; julian.reschke@gmx.de; connolly@w3.org >>>>>> ; >>>>>> www-tag@w3.org >>>>>> Subject: Re: Uniform access to metadata: XRD use case. >>>>>> >>>>>> >>>>>> On Feb 24, 2009, at 9:00 AM, Eran Hammer-Lahav wrote: >>>>>> >>>>>>>> I'll separate the two for my next draft and correct this. >>>>>>>> >>>>>>>> Adding URIQA support in many hosted environments or large corporate >>>>>>>> deployment isn't simple. It sets a pretty steep threshold on >>>>>>>> adoption [1]. I actually like the MGET approach a lot, but I can't >>>>>>>> sell it to 90% of my use cases. Consider me an extreme >>>>>>>> pragmatists... >>>>>>>> >>>>>>>> EHL >>>>>>>> >>>>>>>> [1] http://www.hueniverse.com/hueniverse/2009/02/the-equal-access- >>>>>> principal.html >>>>>> >>>>>> I don't know about hosted environments and corporate deployments >>>>>> generally, but one thing I like about Link: is that in Apache, at >>>>>> least, it can be inserted using a directive in an .htaccess file. >>>>>> >>>>>> http://httpd.apache.org/docs/2.0/mod/mod_headers.html >>>>>> >>>>>> It looks as if the Apache 'script' directive could be used to enable >>>>>> URIQA, but it requires installation of a CGI script (or something >>>>>> similar), raising the bar a teeny bit (perhaps beyond >>>>>> what's practical in certain deployments). (Not that .htaccess is >>>>>> always permitted to use the header directive anyhow.) >>>>>> >>>>>> http://httpd.apache.org/docs/2.0/mod/mod_actions.html >>>>>> >>>>>> The problem is that I believe both Eran and Patrick, who say >>>>>> conflicting things. We have talked a lot about technical merit and >>>>>> generalities. Since the questions of practicality and simplicity are >>>>>> empirical any hard data pro or con either side would be helpful, >>>>>> especially as regards non-Apache platforms. >>>>>> >>>>>> Jonathan >>>> >> >>
Received on Friday, 6 March 2009 06:43:13 UTC