Hi Howard, On Sun, Mar 23, 2008 at 11:15 AM, Howard Chu <[EMAIL PROTECTED]> wrote: > Using cursors for walking entry lists (and saving the cursor state) is > certainly useful inside the server, but there's nothing you can safely gain > from the client side.
Well, the mechanism by itself can be used. The way we implemented the browser would certainly benefit from ushc a mechanism. Of course, you will have no guarantee that the data are up to date (and we have added a refesh button just for this case) > > It kind of sounds like you're talking about Virtual List Views, not paged > results. Remember that search responses in LDAP/X.500 are unordered by > definition. Therefore it makes no sense for a standards-compliant client to > send an initial request with a Paging control saying "start at responses > 200-300" because the order in which entries will be returned is not defined. Here, I don't think that a standard client will benefit from such a feature, that's for sure ! However, due to the internal structure we use (BTree), there is no reason why we should not let the client to benefit from this. Also considering that the client offer is quite poor atm, if you except jexplorer, ldapbrowser and softera - I don't even mention the atrocious text-based GUI delivered by M$ ... -, I'm not too worried about the installed base :) > You need something like VLV which requires SSS to even begin thinking about > this; it's not a job for Paged Results. Pages result can be extended a bit, to offer more capabilities. Of course, this will result in another RFC. > > Even if you have a stable ordering (which SSS is actually unable to > guarantee) > you still can't reliably identify response #200 since underlying entries may > be added or deleted while the search is progressed. Yes, and this is something I mantionned in my previous mail. We also need to have a decent cache system in order to guarantee that the search result is 'fresh'. Not simple, but possible. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
