Injecting custom instance of IConnectionMultiplexer

[Petr Kozelek (footcha)]

This PR contains initial implementation of #105.
Your feedback is welcome.
Thank you for your work!
BR
Petr

[Microsoft Contribution License Agreements (msftclas)]

All CLA requirements met.

[Siddharth Chatrola (SiddharthChatrolaMs)]

Petr Kozelek (@footcha) I haven't got time to look into this yet. Once I am done with my current task, I will verify this and update this thread. Sorry for the delay

[Petr Kozelek (footcha)]

Siddharth Chatrola (@SiddharthChatrolaMs) Is there any progress in a code review? Any estimate when you will be able to provide a feedback?
Thank you,
Petr

[Jon Cole (JonCole)]

Our team is pretty slammed right now and we probably wont get to this right away. One thing that jumps out at me is some concern over the fact that you are using an interface for the factory, which makes future changes/behaviors around controlling the multiplexer challenging. At the very least, I would think we should consider an abstract class instead of the interface, which would allow us to add new, virtual methods if the need arises. However, if you have other suggestions, those would be great to hear.

[Petr Kozelek (footcha)]

Jon Cole (@JonCole) Thank you for a response. I understand your suggestion to replace an interface-based factory with an abstract class. I will do that.

[Jon Cole (JonCole)]

Petr Kozelek (@footcha) - one of the other things that I am concerned about with this PR is the fact that this effectively exposes some internal abstractions that aren't necessarily designed sufficiently to be ready for public consumption. For instance, before accepting this PR, I would want to think about how far we think we want to take the abstraction around the connection. Do we want to allow app developers to control the calls to the multiplexer? Do we want to let developers replace StackExchange.Redis entirely with some other client library? I think we need to answer some of these longer term plans around extensibility before we can decide if your PR has the right long-term design.

Unfortunately, our team doesn't currently have the cycles to spend time digging into the longer term extensibility plans, thus the desire on my end to wait a bit longer before acting on this PR.

Happy to hear thoughts/feedback from you and others as well on this topic...

[Jan Vilimek (jvilimek)]

Hello, has someone already time to finish review/merge? Jon Cole (@JonCole) ? Siddharth Chatrola (@SiddharthChatrolaMs)

[Aravind Yeduvaka (aravindyeduvaka)]

Hey sorry about the delay but our team has been pretty busy.
Jon Cole (@JonCole) and I discussed this but we don't see a strong need for this since configuration settings allow users to customize the settings that most care about. Unless you feel that there are strong reasons to do otherwise, we are leaning towards saying no to this PR.