Re: Comments on LDP-Paging

On Wed, Jul 30, 2014 at 11:35 AM, John Arwe <johnarwe@us.ibm.com> wrote:
>
> > <#MISSING?>
> > Server indication that is has given up on paging and client should
> > start "fresh".
> > There was some discussion of allowing for a server to indicate that
> > the in-sequence page resource is "no longer" valid and the client
> > should re-initiate paging.  I believe Sandro had proposed using 410-
> > Gone (of course all the right paging response headers would be
> > present, rel=first, etc).  Is there another way a client can detect
this?
>
> In the current live drafts, the only mentions of abandon or 410 are in
the non-normative notes on 5.1.4 and 6.2.9, which talk about the server
abandoning a page sequence.  Only 5.1.4 specifically mentions 410; both
mention 4xx, which I think is the general case.  How a client reacts to
that is IMO up to the client.
>
> Of course even IF the server uses a 410 for this case, the client can't
know that it's seeing 410 specifically because the page sequence was
abandoned; it could be for other reasons, like the paged-resource itself
being deleted by a competing request.

Understood, some clients will know this is a page and know that 410 means
that a sequence MAY be abandoned.  Then it goes back to the paged resource
and checks the paged resource (HEAD/GET), it gets a 410, it would know that
the paged resource (and all its pages) are "gone".  If it gets 2xx, it
knows paged resource still there and happily starts flipping through pages
again.

> > <#MISSING?>
> > OPTIONS & HEAD
> > I only see the "HTTP GET" section, HEAD is pretty straightforward
> > and not sure we need to call it out (though we do in LDP).  I think
> > these response headers would be valuable on OPTIONS as well, no?
> >  Did we ever discuss this or has it been considered?
>
> I think we had HEAD in LDP because we specifically required it for LDPRs.
 Since everything in Paging is already in LDPR, and we don't add anything
new, we're silent.
> I don't recall any discussion about OPTIONS.  I see that we currently
define pages as LDPRs, so support is required.
>
> The response headers is an interesting thought; I've never been
completely comfortable requiring OPTIONS in LDP, and I don't see (yet?) how
the response headers would help me with paging vs just doing the GET
paged-resource-uri and potentially getting a 2nn or 303 back.

Well, if the client had some knowledge that the thing at the URL could be
paged, it might just want to know the URL for the first page (and paged
resource etag).  So if you go through all that trouble, it is almost the
same as HEAD.  Perhaps you save on sending content-type and content-length.

My observation was more about if the omission was intentional or not.  I'm
fine with not requiring them as I attempt to find cases where I'd use it,
seems quite narrow.

> > I'd propose we add a clause that says something of the sort:
> > [[LDP Paging servers SHOULD indicate that they have abandoned a
> > sequence by responding with at 410-Gone to any of the in-sequence
> > pages with appropriate paging link response headers, rel='first']]
>
> I'm a little confuzzled on the placement of this (410, then options/head,
then a proposal on 410).

It seems I had walked away and them picked up in a different spot, the
proposal was intended to be with 410 discussion just above.

> I'm agnostic at this point as to the value of SHOULD-410, since it
doesn't give clients any new guarantees.

Well, it helps guide them in a closer direction (see above).  Which I think
still provides value, otherwise impls will just make up stuff.

> The response headers is an interesting thought;
(Hmm, you say the same lead in above)
> I take it you're thinking that the 4xx would have the "new first page"
etc links.  Technically, the clauses as now worded in 6.2.10-16 apply to
4xx requests as well (they don't qualify [successful] GET requests), so
'next' (unless also last) + type='page' is required, which seems like a
perverse result to some degree.
That is correct, using the idea that somehow encoded into the in-sequence
page links is knowledge of the boundaries of the page, it would seem that
the first-page-link URL would change.

> [going waaaaay out on a new branch from that point...thinking out loud]
> If the client supports 2NN, the server could I think legally return
2NN+new-first-page in this case.
> Else If the client supports LDP paging, '303 to the new first page' could
be made to work, with changes below
> Else 4xx seems required, and the headers won't help it anyway, although
it is true that the only way a non-paging-aware client could get to this
case is if it was given "a URI" that happened to be a page URI.
>
> changes for "303 to restart traversal", might well also apply to 2nn case:
> - paging client needs a way to tell that what it got is *the first* page
in particular (it requested the n>=1st page), which currently is a known
only via the client's point in the interaction not via response content;
trivial to solve with a Link: <303-location-uri>; rel='first' header.
> - that might serve to distinguish sufficiently between "sequence
abandoned" (this new 303-on-a-page case) and other error cases apropos your
original comment above ... I think the only new *normative* text would be
for the link on 303.
>
"the link" is the link header sample you show above?  To play it out, the
"303 to restart traversal" client would have to be smart enough to compare
Link: <303-location-uri>; rel='first' and Location header uri, of they
match, then "this is not the page you were looking for, give up on paging,
and start here".  A client not aware of this, just following links and
consuming RDF, could keep going on for a while with a bunch of redundant
stuff (not sure this something we can completely avoid but just pointing it
out).  I kind of like 410-Gone approach instead, if client had previous
copies of first/last/next, it could check those and check the paged
resource.  Though don't have a very strong opinion.

> I'm not convinced we need any of that in 1.0 vs .next, but if we decide
we need it, seems like an option that works.
> [end]
I think with 410, it would just handle it.  If we wanted something more
with a "303 to restart traversal", agree getting more experience would be
good (i.e. save for .next or .never).

Thanks,
Steve Speicher
http://stevespeicher.me

> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jul/0059.html
>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Cloud and Smarter Infrastructure OSLC Lead
>