Re: ISSUE-36: Summary of ways of making containers

On 24 Jan 2013, at 01:38, Arnaud Le Hors <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.

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/