[OJ]

Thanks again for the comment.

Your "protip" implies that "needed" is a known quantity, which it isn't in this case. It's a new project, new development without any clients at all. Personally, I would rather give too much flexibility and wind it back after a while than not give enough flexibility and have nobody use it because they can't configure it to their needs. The last thing I would want to have happen is for people to give up an attempt to use it because it isn't able to do certain things. That to me is not a protip if you're hoping that people will use it.

I wish I could post saying "Hey this has been proven on ..." but I can't, because it hasn't. My personal credibility has nothing to do with it at all. If you evaluate software purely on someone's credibility then you'd have barely anything to choose from.

For me, it's solving a problem that I have, and solving it quite well. From the feedback I've got elsewhere, others have felt the same and don't really have an issue with a typical XML configuration that you find in almost any .NET application.

While I appreciate the idea, I am not dumping the XML. It's idiomatic .NET configuration, and I am not going to fly in the face of this convention due to my, or any other person's, bias against XML.

You can specify the configuration through code, the XML-driven config is just one way that you can configure it.

I'm not sure which twenty lines of boilerplate you're talking about. I see 2 for configuration, and one to create a client. I don't see the redundancy, and I also don't see any of the configuration as useless. Each entry serves a specific purpose, and can be specified or left as a default (except for important properties such as host name). I don't believe that forcing hard-coding of configuration is a better option over XML, particularly in the ecosystem this library lives in.

> Read the rest of what I said.

I read it. Multiple times. And that was before I responded.

equark is saying that he doesn't want to write boilerplate code. You're saying that XML config is redundant and sitting around uselessly. I don't see those as the same thing.

If you don't work with .NET then obviously this library isn't targeted at you. Hence, feel free not to use it :)

Personally this difference of opinion is moot, as the configuration/wiring of settings is such a small part of the library. It is possible to configure it easily to fit your environment, even if it's 1 or 2 lines of code more than you'd like.

I'd be keen to hear what you had to say about the other 98% of the code. ie. The bit that actually does something interesting.

Thanks for the critique.

[equark]

My design preference is to make sure the default option feels natural in the f# or ironpython interactive console. I should be able to interact with Riak with no XML and one line to connect. Obviously it's only 2% but it's the first 2%.

[OJ]

This is the most interesting point made so far. Agreed, I had not considered the likes of FSI. That does come with the issue of being painful reading XML config from app.config files, but can easily be handled via what we have.

Would you consider this to be out of the question:

    open CorrugatedIron.Comms
    
    let cluster = RiakCluster.CreateFromConfig("section", "path/to/file.config")
    let client = cluster.CreateClient()

[equark]

You should at least offer a no config file option, so I can just point to my localhost when testing things out.