Re: clarifying containment vs membership

On 2/19/14 6:58 PM, Sandro Hawke wrote:
> On 02/19/2014 04:50 PM, Steve Speicher wrote:
>> On Wed, Feb 19, 2014 at 4:16 PM, Sandro Hawke <sandro@w3.org 
>> <mailto:sandro@w3.org>> wrote:
>>
>>     On 02/19/2014 02:09 PM, Steve Speicher wrote:
>>>
>>>     On Wed, Feb 19, 2014 at 12:34 PM, Sandro Hawke <sandro@w3.org
>>>     <mailto:sandro@w3.org>> wrote:
>>>
>>>         On 02/19/2014 12:18 PM, Sandro Hawke wrote:
>>>>         As I read the spec, it seems to me that normally a
>>>>         container contains exactly the same resources it has as
>>>>         members.
>>>>
>>>>         The one circumstance I can see where this would not be true
>>>>         is when ldp:insertedContentRelation is used.
>>>>
>>>>         I think this is reasonable, but I'm not at all sure I'm
>>>>         reading things right.
>>>
>>>         To be clear, some people think I'm not.   The spec says,
>>>         very cryptically:
>>>
>>>             A LDP Direct Container or LDP Container's membership
>>>             triples MAY also be modified via through other means.
>>>
>>>         Like what?     It also says, "LDP servers SHOULD NOT allow
>>>         HTTP PUT to update a LDPC's membership triples", so... what
>>>         are those other means.   Is it the cases of the server
>>>         violating the "SHOULD NOT"?
>>>
>>>
>>>     PATCH or application specific behavior (like membership triples
>>>     may just appear, such as events in a log on the server).  I
>>>     wonder if SHOULD NOT is right after the containment resolution.
>>>      Personally I'd like to just generalize it to say "LDP servers
>>>     SHOULD NOT allow HTTP PUT to update a LDPC but instead use
>>>     PATCH." and we'd avoid other problems.
>>
>>     Ah.   What's wrong with PUT, then?     PUT is semantically the
>>     same as PATCH, just slower.     I took the prohibition on PUT to
>>     be a prohibition on changing the membership triples.
>>
>> That is because you are a quad-store thinking kind of guy.  I have a 
>> product built on various storage technologies (including quad-stores) 
>> that exposes its resources as LDP resources.  There is a hefty amount 
>> of application code (access control, pulling from multiple data 
>> sources, inter-resource dependencies, ...) that goes it in front of 
>> what an exposed LDP R or C are.  So in order to properly (and 
>> efficiently) handing PUT, we need to run it through the modify action 
>> of each requested change.  We could diff the PUT request with current 
>> state of the resource and make up our on PATCH, but as you can see 
>> there is inefficiencies in having to get the resource and then diff 
>> it with the incoming entity body content.
>
> Yeah, that seems like a case where your server should say "sorry I 
> don't do PUT on containers" rather than as now, where the spec says 
> ALL servers SHOULD NOT allow it.

+1


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen