- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Mon, 6 May 2013 21:05:33 +0200
- To: Steve Speicher <sspeiche@gmail.com>
- Cc: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, John Arwe <johnarwe@us.ibm.com>, Nandana Mihindukulasooriya <nmihindu@fi.upm.es>, Linked Data Platform Working Group <public-ldp-wg@w3.org>
- Message-ID: <CA+OuRR-eMf=13VNpBxAo15ct6Wayg_YtN5cd7skt60HqBOyK5w@mail.gmail.com>
On Mon, May 6, 2013 at 8:42 PM, Steve Speicher <sspeiche@gmail.com> wrote: > On Mon, May 6, 2013 at 12:04 PM, Pierre-Antoine Champin > <pierre-antoine.champin@liris.cnrs.fr> wrote: > > John, all, > > > > granted, the X-Cacheable-for is a hack, in a way, because the container's > > representation (CR) is *not* the representation that you would get for > the > > member (MR). My intuition was that, since the CR inlines the MR (my > reading > > of that being: it parses to a superset of its triples), it can be used > *in > > place* of the MR. > > > > True, this assumes that the client will know what to *look for* in the > MR, > > and will gracefully ignore spurious triples from the CR. This might be > too > > strong an assumption in the general case, but I think it also affects > other > > solutions. Granted, other solutions are less opaque (operating at the RDF > > level, and not the HTTP level), but still, they can't tell the client > which > > triples belong to which representation. > > > > True also, a client might want to PUT the CR back to the member URI -- > which > > would be perfectly valid from an HTTP point of view, but may lead to > > undesirable results. I confess I had overlooked that point. This won't > be a > > problem if the server requires If-Match: with a correct etag for PUT > > requests, but as this is only a SHOULD in the LDP-REC, but LDP-server are > > not mandated to require that. > > So if we adopt the X-Cacheable-for solution, we should probly state that > > servers using it MUST require If-Match: headers in PUT requests. > > > > This would seem to imply that in order to get the correct etag, the > client would need to GET first the resource and then PUT back with > updates and If-Match. Though if I had a PATCH solution, I might want > to use the etag without the full resource? > Yes, but that is equally true of someone having a stale representation of the resource, and wanting to update it. My point is: there are already cases when you need an extra GET before you can do a PUT. This proposal just adds one to the list. > Separately, I think it is fair to say that it is questionable whether > the MR within the CR could accurately use this to update an HTTP local > cache. Though it may have a LDP-R cache where it could help. > Obviously Richard thought so, that is why he opened the issue to begin > with ;) > Exactly :) It appears, after this discussion, that inlining is no silver bullet. It can prevent unnecessary GETs in *some* situations, but not all, whichever option we chose. So something like this could evolve for D (and possibly others): > > LDP-Inlined-Member: <http://example.org/netWorth/nw1/a1>; > ETag="737060cd8c284d8af7ad3082f209582d" > LDP-Inlined-Member: <http://example.org/netWorth/nw1/a2>; > ETag="737060cd8c284d8af7ad3082f209582e" > Do you expect these ETags to be "recognized" by the member when GETing ot PUTing its URI? About GET, this seems farfetched, as it is not *really* the same content. About PUT, this seems also risky, as you trust the client for pruning all the irrelevant triples... I would rather have no ETag attached to the cache entries generated by option D, so that subsequent requests to the member URI will set things straight. pa > - Steve > > > > > > > On Mon, May 6, 2013 at 4:15 PM, John Arwe <johnarwe@us.ibm.com> wrote: > >> > >> > This issue of knowing which triples belong to which resource applies > >> > to equally to all the four options, right ? Though we discuss it in > >> > >> The options are asserting markedly different things. > >> > >> All of them do assert (at the RDF level) that the response triples > include > >> all the triples one would get by retrieving the named members as well. > >> > >> None of them make any assertion about the correspondence between HTTP > >> resources and triples returned. > >> > >> That is sufficient for the simplest container-client case (query). I > >> think it wholly insufficient for any scenario involving later > replacement > >> (PUT) of the intervening resources, in the absence of assumptions about > the > >> relationship between triple subjects and HTTP resources (other thread). > In > >> other words, if you intend to replace the members later I do not see > how you > >> are going to avoid getting those members first. PATCH, being more > >> incremental, might be less of an issue. > >> > >> Best Regards, John > >> > >> Voice US 845-435-9470 BluePages > >> Tivoli OSLC Lead - Show me the Scenario > >> > > >
Received on Monday, 6 May 2013 19:06:01 UTC