Expose configuration options interface?

[Eibwen]

Expose configuration options interface?

[highlyunavailable]

If you have a suggestion on what would work for you to do that, please let me know. The reason it's set as internal is that I don't want to allow the user to change it "midflight" because it's not really threadsafe internally and is used in every call to build the call up, so I'd rather not lock on every field, and I can't think of a good way to make it "read-only after initial buildup".

If you'd like to take a reference to the config for testing, it can be done inside the action:

ConsulClientConfiguration myConfig = null;
using (var client = new ConsulClient((config) => { config.Datacenter = "foo"; myConfig = config; }))
{
    Assert.Equals("foo", myConfig.Datacenter);
}

This may not be ideal for you but if you can write your wrapper to return a reference to the config that was supplied inside the action, that should work for testing.

[Eibwen]

Thanks for the quick reply and workaround!

(Maybe read conclusion at end first)

My initial thought was to create an interface with all the setters removed. All the ones with getters are immutable types so this should be safe:

public interface IConsulClientConfiguration
{
    /// <summary>
    /// The Uri to connect to the Consul agent.
    /// </summary>
    Uri Address { get; }

    /// <summary>
    /// Datacenter to provide with each request. If not provided, the default agent datacenter is used.
    /// </summary>
    string Datacenter { get; }

    /// <summary>
    /// Token is used to provide an ACL token which overrides the agent's default token. This ACL token is used for every request by
    /// clients created using this configuration.
    /// </summary>
    string Token { get; }

    /// <summary>
    /// WaitTime limits how long a Watch will block. If not provided, the agent default values will be used.
    /// </summary>
    TimeSpan? WaitTime { get; }
}

Then have public IConsulClientConfiguration Config { get { return _config; } }

Although this idea would allow someone to manually cast it back to ConsulClientConfiguration and mess with it.

Exposing NetworkCredential or Certificate or other class types would be riskier because properties on them could possibly be modified.

An alternative would be to have properties on the Client which would be getters only. Which that makes the Client interface more confusing...

Conclusion So now that I explored it a little, neither of these ideas are amazing, and I'm not sure how much value it adds at all... So I'd probably vote keep it how it is :)

[highlyunavailable]

Sounds good - I vote for leaving it as-is too, since you have a workaround in that you can "export" a reference from the action if you really need it, though that does leave a reference dangling outside the using, which should be OK for tests but not for "real" use.