Re: TWO PROPOSALs involving Prefer - volunteering for the army

On February 28, 2014 9:42:05 AM EST, Roger Menday <roger.menday@uk.fujitsu.com> wrote:
>>>>> 
>>>>> Why? Because I think the client that wants to POST to an
>>> ldp:DirectContainer or an ldp:IndirectContainer will want to do a
>>> conditional POST.  Otherwise how
>>>>> does the client know that the server has not changed the
>membership
>>> properties between the time it read the content and the time the
>POST
>>> arrived? 
>>>>> I wonder if this has been thought through enough? It seems to
>>> suggest that an ldp:(In)directContainer should not have its etag
>change
>>> unless those properties 
>>>>> change.
>>>> 
>>>> The Working Group has not accepted your proposal that clients MUST
>>> understand the membership triples before POSTing. I'm pretty sure
>many
>>> of us would formally object to such a proposal.
>>> 
>>> I disagree. this is already in the current spec. I am just making
>what
>>> is there a bit more explicit by
>>> taking a admittedly extreeme example. If you want to formally object
>>> what would be your 
>>> grounds for doing so?
>> 
>> My grounds would be that it would require clients to do things I do
>not believe they will do.   I could be persuaded by evidence of what
>real clients actually do.
>> 
>> Your examples are constraints on the server not the client.   When I
>buy something from the grocer, it precipitates a whole chain of events,
>some of which are visible to me and some of which are not.   I don't
>need to understand them all before I buy something.    If I were
>required to understand them all, I probably wouldn't buy as much.
>> 
>> You want every client to hard code the membership predicate it's
>going to find in a container and refuse to post if it's not there?  
>
>
>A client will need to understand (and like) what will be created and
>how it will be linked to decide if it wants to go ahead. 
>

I'm not sure what you mean by "understand" and "like" if you don't mean the client MUST get fetch the membership configuration and MUST match a pattern hardcoded into the client software, including the predicate URI.

I think that's overly restrictive, by quite a bit.     It could be useful to prevent a class of error, I suppose, but I think it will cause more problems than it solves.

I'm fairly sure most client implementors will ignore this rule, because it's easier on them and will probably result in fewer user complaints.

    - Sandro

>Roger
>
>
>>   Or is there some other kind of understanding you have in mind? 
>Steve, are you okay with that requirement on your software and the
>software of your customers?
>> 
>>    - Sandro
>> 
>>> Here are just some of the reasons for my position: 
>>> 
>>> => POST in http is non idempotent. POSTing does things. And when an
>>> agent does things in a space
>>> where there are rules. That is why one does not just POST anything
>>> anywhere. 
>>> => The consequences of POSTing to a all forms of LDPCs  are known to
>>> the client and explicity stated in the spec:
>>> 
>>> 6.4.3 When a successful HTTP POST request to a LDPC results in the
>>> creation of an LDPR, the LDPC must update its membership triples to
>>> reflect that addition, and the resulting membership triple must be
>>> consistent with any LDP-defined predicates it exposes. A LDP Direct
>>> Container or LDP Container's membership triples may also be modified
>>> via through other means.
>>> 
>>> There are a huge number of reference throughout the document to
>>> membership triples. You cannot really write a client that uses
>>> ldp:IndirectContainers
>>> or ldp:DirectContainers without understanding that concept. The
>>> differences are then made clear.
>>> The following table illustrates some differences between membership
>and
>>> containment triples. For details on the normative behavior, see
>>> appropriate sections below.
>>> 
>>> Completed Request Effects
>>> Membership Containment
>>> LDPR created in LDP-BC New triple: (LDPC, ldp:contains, LDPR) Same
>>> LDPR created in LDP-DC New triple links LDP-RS to created LDPR.
>LDP-RS
>>> URI may be same asLDP-DC New triple: (LDPC, ldp:contains, LDPR)
>>> LDPR created in LDPC New triple links LDP-RS to content indicated
>>> URI New triple: (LDPC, ldp:contains, LDPR)
>>> LDPR is deleted Triples may be removed Triples are removed
>>> LDPC is deleted Triples and member resources may be removed Triples
>of
>>> form (LDPC, ldp:contains, LDPR) and contained LDPRs may be removed
>>> 
>>> I could find more I am sure.
>>> 
>>> Henry
>>> 
>>> 
>>> 
>>> Social Web Architect
>>> http://bblfish.net/
>> 
>> 
>>

Received on Friday, 28 February 2014 15:32:16 UTC