Support custom callbacks and/or use less final classes

[GoogleCodeExporter]

At the moment, it's not possible to get actively notified when e.g. an
asyncGet has completed without patching the source.

The motivation is to load data not found in the cache as soon as it is
known that it has to be loaded, not at the moment when Future.get()
happens, possibly blocking further calculations.

Current workaround is to make either AsciiOperationFactory or
MemcachedClient non-final in the sources, recompile and extend one of the
classes to be able to override MemcachedClient.asyncGet or provide an own
OperationFactory to supply a customized GetOperation.Callback (which for
example will put the key for a cache-miss in a separate async-loading-queue).

Original issue reported on code.google.com by mibe...@gmail.com on 27 Oct 2009 at 10:30

[GoogleCodeExporter]

I'd welcome whatever you come up with for a callback API.  In the meantime, I'm
marking these classes non-final (I have no good excuse for a final class, but I 
do
like final fields...)

Original comment by dsalli...@gmail.com on 27 Oct 2009 at 5:56

• Changed state: Fixed

[GoogleCodeExporter]

Thanks! After playing with the classes a while, the client feels really awsome.
Thanks for your work!

What I did, was basically overwritng receivedStatus in the inner class in 
asyncGet
with the following logic:

public void receivedStatus(OperationStatus status) {
  // <customized>
  if (val == null) {
    // delegate to some loader service and replace the future returned to the client
    // with the future created by the loader
    val = (Future<T>) _loader.add(key, MyClient.this);
  }
  // </customized>
  rv.set(val);
}

Now if the API would have a method like
public <T> Future<T> asyncGet(final String key, final Transcoder<T> tc, final
Get.Callback callback)
that allowed me to supply my custom logic without hacking MemcachedClient.

BTW: I also do *really* like final fields and use them throughout my coding 
whereever
possible.

Original comment by mibe...@gmail.com on 28 Oct 2009 at 11:59