On Sun, Mar 23, 2008 at 5:35 AM, Emmanuel Lecharny <firstname.lastname@example.org> wrote:
We have to extend this [client] API to cover all the LDAP
operation (connect, disconnect, send and receive messages, controls,
It will be Cursor<Entry> (as this is the top level interface)
> The Partition interface in ApacheDS will soon expose search results by
> returning a Cursor<ServerEntry> instead of a NamingEnumeration.
Further experiments and researches will help a lot here. We may have
> on the filter used, this is a composite Cursor which leverages partition
> indices to position itself without having to buffer results. This allows
> the server to pull entries satisfying the search scope and filter one at a
> time, and return it to the client without massive latency, or memory
> consumption. It also means we can process many more concurrent requests as
> well as process single requests faster. In addition a resultant search
> Cursor can be advanced or position using the methods described above just by
> having nested Cursors based on indicies advance or jump to the appropriate
> Index positions. We already have some of these footprint benefits with
> NamingEnumerations, however the positioning and advancing capabilities are
> not present with NamingEnumerations.
problems too, as this will be a concurrent part : some of the data may
be modified while the cursor is being read.
The major improvement with Client cursors is that the client won't
> During the course of this work, I questioned whether or not client side
> Cursors would be possible. Perhaps not under the current protocol without
> some controls or extended operations. Technical barriers in the protocol
> aside, I started to dream about how this neat capability could impact
> clients. With it, clients can advance or position themselves over the
> results of a search as they like. Clients may even be able to freeze a
> search in progress, by having the server tuck away the server side Cursor's
> state, to be revisited later.
have anymore to manage a cache of data. Thinking about the Studio, if
you browse a big tree with thousands of entries, when you want to get
the entries from [200-300] - assuming you show entries by 100 blocks -
you have to send another search request _or_ you have to cache all the
search results in memory. What a waste of time or a waste of memory !
If we provide such a mechanism, the client won't have to bother with
such complexity. Data will be brought to the client pieces by pieces :
if the client want numbe 400 to 500, no need to get the 499 first
entries. If the client already pumped out the first 100 entries, it's
just a simple request on the same cursor, no need to compute it again.
So, yes, client cursors make sense too.
This way the client has the ability to intervene in whatExactly ! For instance, using negative size would result if going
> otherwise would be a long flood of results in a single large search
> operation. If this page control could also convey information about
> positioning, and directionality, along with a page size set to 1, we could
> implement client side Cursors with the same capabilities they posses on the
backward. This is a very minor extension to the paged search RFC, and
it can even be implemented using the very same control, simply adding
some semantic to it.
Another extension would be to add a 'position' to start with.