Norval Hope wrote:
Hi,
I don't know the core code like you, but given my current
understanding (pardon me if my understanding is woefully inadequate
:-) I'm not sure your option 2 is really viable. After the first page
is returned, how are you going to initialize the cursor for the next
page?
You have to store some session information in any case. So assuming we
implement the second option, we just store the number of entries we
already transmitted.
Wouldn't you have to remember where you were up to (using some
sort of unique per-result key) and rerun the search, skipping results
up to this key value (if so then it's unworkable no?).
Yes, this is exactly what I have in mind :)
BTW Is there
guaranteed to be a stable sorting order for search results internally,
and is the sort control supported by AD so that it may be posed
externally etc.
There are no such guarantee, either with option 1 or option 2, as stated
by RFC 2696 :
"A client may safely assume that all entries that satisfy a given search
query are returned once and only once during the set of paged Search
requests/responses necessary to enumerate the entire result set, unless
the result set for that query has changed since the searchRequest
starting the request/response sequence was processed."
At any rate I don't think keeping a cursor open is that big a deal,
although there probably needs to be a server-side timeout so that if
the cursor is not accessed for a long time (say an hour for argument)
it is automatically closed. Well behaved clients should explicitly
close their NamingEnumerations which I would hope would allow the
cursor to be discarded immediately.
The problem is certainly not well behaved client. but there are many
case when even a well behaved client might be troublesome. Typically,
Apache Studio (a well behaved client, that's for sure :), when it comes
to load thousands of entries, uses this control to get the entries
little by little. It present the entries in a list of N sub-entries, and
when you open a block, then a new search is sent to the server. Another
possibility is to design a cursored presentation of data, with, say, 20
entries per page. The client click on 'next' or 'prev' to get the next
20 entries. As it's interactive, we may have some long period of time
between two interactions.
So sure, we will have to implement a timeout (but we already have a
session timeout), which is a bit painfull, as you need a thread to
manage it.
But anyway, I think this is the way to go too... It's just that it's
painful ! :-]
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
