- From: Alexandre Bertails <bertails@w3.org>
- Date: Thu, 24 Jan 2013 09:20:35 -0500
- To: Henry Story <henry.story@bblfish.net>
- CC: Arnaud Le Hors <lehors@us.ibm.com>, public-ldp-wg@w3.org
On 01/24/2013 04:57 AM, Henry Story wrote: > > On 24 Jan 2013, at 01:38, Arnaud Le Hors <lehors@us.ibm.com > <mailto:lehors@us.ibm.com>> wrote: > >> If I got this right, the premise for doing anything else other than >> using POST the way it's done for other resources is that some don't >> want to pay the price of having to parse the content to find out what >> the type of the resource to be created is. >> >> Yet, it also seems to be accepted that in most cases one will parse >> the content to validate it anyway, if nothing else. >> >> Furthermore, it is also accepted that we can't depend on something >> like MKCOL and we need a fallback mechanism. > > That argument for the moment is I think very weak: it is saying for some > very old browsers that > are unlikely to be able to use LDP because they won't be able to have > fast enough JavaScript to > use them, this won't work. I'd like to know WHICH browsers? Also does > that also cover DELETE, > and PUT and UPDATE? And is it really relevant, when a lot of this is > going to be implemented > by servers outside of browsers. It was never about slow javascript. It's about supporting (or not) HTTP methods other than POST and GET. You can use [1] to test. For background, you can read [2]. I can't test with IE (any version) but [3] says it should be ok with IE >= 8, and there could be some issues with IE 7 and previous. Also, we should test the support for adding HTTP headers. The WG could decide to ignore some browsers, but you have to be prepared that someone can raise an objection at any moment. Alexandre. [1] http://www.mnot.net/javascript/xmlhttprequest/ [2] http://annevankesteren.nl/2007/10/http-method-support [3] http://msdn.microsoft.com/en-us/library/ms537505%28v=vs.85%29.aspx > > Furthermore it can't be that problematic, since Subversion uses WebDAV, > Apple's File > Viewer does it, etc... > > There may be other reasons for not liking MKCOL. ( I can think of a few ) > >> >> Given all that, I have to ask: Why don't we just accept that finding >> out what type of resource needs to be created is a price some will >> have to pay and stick to POST? > > I am not completely against this option either. If one could find a > method so that a POST > of a collection did not require searching the body to see the content, I > would be very much > in favor. ( I also have some thoughts on that. ) > >> >> In practice, I think there are two general categories of use cases. 1. >> generic/vanilla server that simply stores triples and regurgitates >> them without doing anything special with them. 2. application specific >> server - this is a bug tracking system for instance - which translates >> the triples into an actual application specific object. >> >> In the latter case, the server for sure will want to parse the content >> received to figure out exactly what type of object is to be created >> and if the content received has all the bits and pieces required to >> satisfy the application needs to create such an object. So, this >> requirement adds no extra burden. >> >> In the former case, there may be a real additional cost but is it >> significant enough to justify doing anything different? And there may >> be ways to optimize this by deferring that operation to when the >> server is required to actually do anything different. > > I think there may be too. > >> -- >> Arnaud Le Hors - Software Standards Architect - IBM Software Group > > Social Web Architect > http://bblfish.net/ >
Received on Thursday, 24 January 2013 14:20:54 UTC