Re: LDP "paging"

The problem with using "segments" or "chapters" is that no one will understand
what we mean.  "Page"  may be confusing but can be clarified by the context, as in
"page in a paged resource"

Calling the resource a "paged resource" and then calling what it contains "segments"
or "chapters" does not seem right.

All the best, Ashok

On 6/23/2014 9:32 AM, Sandro Hawke wrote:
> I took a fresh look at the LDP paging spec [1] this morning, and I have three main thoughts (and a lot of editorial thoughts which can wait):
>
> 1.  We're not ready to decide on publication today.
>
> 2.  On the issue of terminology [2], I'm now thinking that just changing "single-page resource" will leave something of a mishmash.   It would be much cleaner to have another set of terms which doesn't overlap with Web Pages.   For example "segment", so we'd have "segmented resource" and "segment resources" (or just "segments", less formally).   Or, more fancifully, "chapter", so we'd have "chaptered resource" and "chapter resources" (or just "chapters", less formally).
>
> If we adopt one of those, we might consider changing the name of the spec to match (LDP Segments, LDP Chapters), although I can still see how the whole process could be called "paging", even if you're "paging through segments" or "paging through chapters".
>
> 3.  On the key issue of initiation and interoperability (and thus conformance), I believe this is our current story, reframed in a way that makes sense to me:
>
>     There are five kinds of LDP clients with respect to paging:
>
>     Type 1, the Non-Paging LDP Client.  Ignores first/last/next/prev headers, ignores 303.  If the server decides a resource is too big and tries a 303, this client will break.  LDP Spec says clients SHOULD NOT be like this, but allows them to be like this and still be conforming LDP Clients.
>
>     Type 2, the Silent-Paging LDP Client.  Ignores first/last headers, but follows a 303 redirect and then follows rel=next headers, so it works properly if a server initiate paging using a 303.   If servers assume every client is like this, they can do something like automatic paging for containers with over 1000 members.   But they will be breaking any Type 1 (Non-Paging) clients.
>
>     Type 3, the Paging-Acceptable LDP Client.  Follows 303/rel=next like Type 2, implements 2nn as well, and most importantly sends a Prefer: page-size header, letting the server know it's safe to initiate paging with 2nn or 303.   (Per IETF, 2nn MUST NOT be used unless there is reason to believe the client understands it, and Prefer: page-size is the only way we're defining to give the server that information).   This type of client can stream-process resources and intends to fetch all pages, so it sees no actual benefit from paging.   As such, it might provide a very large page size, but I suggest we define page-size=unlim for this case.
>
>     Type 4, the Paging-Preferred LDP Client.  Like Paging-Acceptable, but it can't stream process, or wants just a little bit of the data, or wants long pauses in streaming, or has some other reason to have a preference for paging of large resources.  So it sends an explicit page-size.
>
>     Type 5, the Tries-Paging-First LDP Client.   Like Paging-Preferred, but first tries doing a HEAD, looking for rel=first or rel=last.  This allows paging from servers that don't do 303 or 2nn.   Also allows paging in reverse order. Falls back to doing a GET if those headers are not present.  I suggest it MUST include the Prefer: page-size header on it's HEAD request, in case the server only pages upon request.
>
> That all seems fairly reasonable.   If complicated.   But I can't see how to simplify it without breaking things.     Personally, I think everyone should aim for Types 3 and 4, but I see why people might need 1, 2, and 5.
>
> There's a corresponding analysis one could do on the servers, but it's a little simpler and I'm out of time.
>
>         -- Sandro
>
>
> [1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html
> [2] https://www.w3.org/2012/ldp/wiki/Names_in_Paging