Alex Karasulu wrote:
As a rule things start getting ugly with API methods when you have more than
4 arguments and more than 4 overloads.
True.
The most important thing to realize is what changes most with each search
request. The base does change most. The filter does but sometimes does not
need to be provided since people just want everything. I can see something
like:
conn.search() => searches the rootDSE ? Or should this be conn.getRootDse()
?
I would rather use a getRootDse() instead of a weird search request with
no baseDn. So +1
conn.search( baseDN ) => searches the base with one level scope and
(objectClass=*)
conn.search( baseDN, filter )
conn.search( baseDN, filter, scope )
We can add those three methods.
Attributes and size/time limits might be best left to be overridden in the
SearchRequest?
I think that the Attributes should be the forth param. Anything else
should be handled using a SearchRequest object.
However these parameters should be set to some smart default
when using the signatures above. For example the sizeLimit may default to
1000 entries.
Exactly.
NOTE: timeLimit != timeout where the timeLimit is the limit for a search
operation on the server, and the timeout is the time the client will wait at
most for any operation to complete before disconnecting/abandoning the
client request.
TimeLimit is handled by the server, not the client. So yes, they are
different values. We should have a default timeout value on the client,
stored into the connection though.
Also I was wondering how the Cursor interface fits into this. Right now we
used the DirectoryListener.
Man, it fits just fine :) You have to see it...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
