Re: clarifying containment vs membership

On Wed, Feb 19, 2014 at 6:58 PM, Sandro Hawke <sandro@w3.org> 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> 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> 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.
>
>
I think we are in agreement.  I was answering your question on what's wrong
with PUT, not building a case for the SHOULD NOT.  In another thread I said
that after last resolutions, I wonder if this was too strong.  I will flag
it as something for next meeting to discuss.

- Steve

(trimmed rest of thread)