That would mean implementing and maintaining Futures supporting callback when we have such implementation available from Guava. Are you sure it's a better way to add support for callbacks?
Best regards, Piotr On Wed, Jan 2, 2013 at 3:04 PM, Kiran Ayyagari <[email protected]> wrote: > and at the same time no dependency on another lib (guava etc.) please > > On Wed, Jan 2, 2013 at 7:31 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 >> >> > > > -- > Kiran Ayyagari > http://keydap.com
