[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [Fwd: Re: Paged Results and limits]
Seems to be some confusion over this limits stuff.
Though I would provide some comments to help
sort this stuff out. Personally, I think the limits
have gotten overly complex.
For a particular search (whether it spans one operation
or multiple, there are two basic policy (server-side limits)
items (which may depend on the particulars of the search:
who? what? paged? etc.)
1) test no more entries than the candidate limit
2) return no more entries than the entry limit
(should be less-than-or-equal candidate limit)
For paging, there are two additional policy items:
3) return no more entries on a page than the per-page
entry limit (should be less-than-or-equal entry limit)
(could be used to disable paging)
4) return no more pages (per search) than the page limit
(could be used to disable paging)
(but ignore this item for now)
Just from the above, we have four items which could
be determined for the particular operation and then
evaluated during the processing of the operation.
Separate from this is whether or not a size limit requested
by the client is to be honored or not... and whether there
is a default limit which applies when no limit is requested.
So, we have as input to determining (2) (the limit used in
processing):
a hard entry limit
a default (soft) entry limit, and
a requested entry limit.
If request is over hard, we error. If request is not provided
(e.g., no-limit), then we use the default limit (2). Otherwise
we use the request limit for (2).
So, limit command needs just:
size.unchecked for (1)
size.hard for (2)
size.soft for (2)
size.page for (3)
(with size.page used to disable paging)
(We can defer adding pagecount limit.)
We may also want different limits by who but on particulars of the
operation. Such as, one might want to have a larger size.soft
when paging is used. Or when manageDsaIt is used. Or when
foo is used. Because these particulars are orthogonal to
who, what, and the limits, we need to have an orthogonal
syntax. Something like:
size.hard/pagedresults (when paging results control is present)
size.hard/manageDsaIt (when manageDsaIt control is present)
size.hard/pagedresults/manageDsaIt (when both are present)
However, I think we should avoid that complexity for now.
And since prtotal is not an orthogonal syntax, I think we
should remove it.
Kurt