Re: Implementing SSS/VLV, questions.

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

When one considers SSS by itself, one obvious approach is to
use ordering indexing to produce sorted candidates.  That way,
you only have to manually sort items which share the same indexing
key.  Of course, where you don't have ordering indexing (like
everywhere in OpenLDAP) or that ordering indexing is in-effective,
you end up sorting everything (or lots) manually.

When you consider SSS combined with paging (or any of the VLV
variants), then one needs to worry about continuity of the
results.

In our present paging implementation, we just remember the
entry ID where we left off.  This is sufficient information
to start the new page immediately after where the last page
left off (as IDs are stable).

However, when dealing with sorted entries, their position in
the result set may change dramatically.  To avoid these problems,
one needs to produce sorted entry set just once, and use a position
indicator in that set.  This also avoids determining candidates
on each page request and resorting all entries on each page request.
But it does mean storing a sorted list of entry IDs for the
result set.

There are a couple of problems with implementing outside of
backends (such as directly in the frontend or in an overlay).
The most obvious, and likely the most difficult to overcome,
is that if the backend did support ordering indexing, it would
be difficult to use it in support of sorting.  But since
we have no backend which supports ordering indexing, one could
leave that to others to address.

Anyways, if I were implementing this, I'd would opt for a
frontend/overlay implementation so that it could be applied
to any and all backends.

Regardless, I'd want some authorization facility to limit who
could use it and to what extent.  We really need a general
"authorization to use access mechanism" facility (in addition
to our "authorization to access information" facility).  But
this can (and should) be developed independently from any SSS
implementation.

Also, if you are going to implement SSS, it might be wise
to consider whether you need Duplicate Entry
(draft-ietf-ldapext-ldapv3-dupent-xx.txt) support as well.
This ensures that an entry which has multiple values for
search key are listed multiple times, once for each value
of the search key, in the results.  That is, if someone
has two names and you sort by name, the entry will show
up in the results twice, once for each name.  If you need
dupent, that likely will alter how you store the sorted
paging information.

I'm not a big fan of VLV (at least the variant(s) which
you likely are referring to).  See IETF LDAPEXT discussions.
Most of my concerns have to do with continuity (which can
be addressed by storing the "list" state).

Kurt

At 07:56 AM 4/9/2004, Konstantin Kunshchikov wrote:
>Hello!
>
>I'm investigate the idea of implementing SSS/VLV extensions in OpenLDAP.
>How it is the best way for implement this? 
>I think using SLAPI for these purposes not so well as by a code - the
>server not ready for this purpose.
>Whether it is necessary to modify struct Operation and
>slap_send_search_entry() or is it possible to do with callback such as
>op->o_callback()?
>How to notify o_callback() on last result (the termination) of the
>search to return sorted results back to the client?
>
>Thanks,
>Konstantin.