Does it mean you don't mind adding Guava as a dependency? Usage of Future with callbacks would be the most flexible and with minimal changes in the code.
If there is no objection, I can create a patch and submit it in JIRA issue. Best regards, Piotr On Wed, Jan 2, 2013 at 3:01 PM, Emmanuel Lécharny <[email protected]> wrote: > Le 1/2/13 2:26 PM, Piotr Bzdyl a écrit : >> Hello, >> >> I started looking at the LDAP Client API and noticed that is doesn't >> support callbacks on the futures returned by various >> LdapAsyncConnection methods. >> >> Was it considered to add such callbacks? It could be easily >> implemented by extending ListenableFuture from Guava library instead >> of implementing bare j.u.c.Future. All implementing classes (e.g. >> AddFuture) could be implemented by extending SettableFuture so it >> shouldn't involve much coding. > > That's an interesting question. Currently, we assumed that we get back a > Future, and the client is responsible to call it when it needs some > result. Most of the time, it's just cosmetic, as you should get the > result immediately, except for requests like Search, Persistent Search > and Replication. > > But in some case, it could be interesting not to block on a > Future.get(), but to pass a callback which gets executed when the > response arrives. It should be a minor extensio to the existing API. We > can even do that without any Future : something like void search( > Callback callback, Dn baseDn, String filter, SearchScope scope, > String... attributes ). > > We welcome any patch :) > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
