- From: Steve Speicher <sspeiche@gmail.com>
- Date: Mon, 6 May 2013 16:17:07 -0400
- To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Cc: John Arwe <johnarwe@us.ibm.com>, Nandana Mihindukulasooriya <nmihindu@fi.upm.es>, Linked Data Platform Working Group <public-ldp-wg@w3.org>
On Mon, May 6, 2013 at 3:05 PM, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr> wrote: > 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. I should have been clear, it was a proposal but more of an exploration of what it might look like. I agree, attaching etags seems to add a bunch of overhead to compute when a client or cache can't do anything reliably with them. A client or cache may want to indicate its freshness MR information but could do so using other methods (time stamps). -- Steve > 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 20:17:34 UTC