Re: LDP "paging"

I agree with Ashok. :-)
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Ashok Malhotra <ashok.malhotra@oracle.com> wrote on 06/23/2014 08:51:39 
AM:

> From: Ashok Malhotra <ashok.malhotra@oracle.com>
> To: public-ldp-wg@w3.org, 
> Date: 06/23/2014 08:53 AM
> Subject: 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