Extending MemcacheClientBuilder to more easily allow other AbstractMultiMemcacheClient impl

[jreilly650]

Hi,
I am currently looking at using folsom. One thing I want to do it to implement my own sharding (to match existing impl). To do this, I was planning to implement a class extending AbstractMultiMemcacheClient similar to KetamaMemcacheClient.

Initially I was planning to extend MemcacheClientBuilder, noticing that the MemcacheClientBuilder.connectRaw method is protected, however on closer inspection I noticed that many fields that one might want to use in that method (such as this.addresses) are not accessible. Would you have any objection to a patch that changes the current set of fields from private to protected?

Another possible alternative I was thinking about is addition of a method to the builder that allows one to pass in the code to create an AbstractMultiMemcacheClient given a list of addresses. e.g.

MemcacheClientBuilder<V> withRawClientCreator(Function<List<HostAndPort>, RawMemcacheClient> clientCreationFunction)

Then in connectRaw, use the function if it is not null, otherwise use the existing logic. Either something like this, or being able to extend and override connectRaw would work for me, but I'm wondering if there would be any interest in a solution like withRawClientCreator? Let me know what you think.

Thanks!

[spkrka]

Thanks for the issue!

For me it would be easiest to think about this once the PR is prepared for review. It sounds reasonable to me now, but perhaps there is some detail that makes it preferable to do it in some other way.

I think in general it seems useful to think of MemcacheClientBuilder is a convenience structure, but it should be possible to set up the client in a more customized way. Exactly how to do that, I am still a bit undecided.

If the PR is not too bothersome to create, let's start with that, otherwise I can spend some more time to think about it.

[jreilly650]

Yeah, that makes sense. I'll put together a PR as soon as I can.

Cheers!