[jallmann]

It sounds like you're making a lot of assumptions about its use case, without actually using it in production. This whole thing sounds drastically over-designed.

And that initialization code is symptomatic of everything that is wrong with the statically-typed OO world. If you really need all that XML, what's wrong with this?

  var cluster = new RiakCluster("riakConfig");
  var client = cluster.CreateClient();
  var value = client.Get("my_bucket", "my_key");

...and I suspect you could probably omit the parameter to RiakCluster, since it appears to be fixed. If lib users need more control over configuration, then they can write extra code towards that. Don't require it for the basic, default case.

[OJ]

jallman,

You're right, we are making a few assumptions, which to me is natural given that this is v0.1.0. It hasn't been used it production because it never existed before now.

I fail to see how enabling clustering and connection pooling via configuration is over-design. Perhaps you could share some more detail on that?

The first line of your code sample is making assumptions itself. No, you can not omit the parameter to RiakCluster, the section name in the configuration is not fixed and is configurable by the user. This means you can have multiple clusters if you want to and configure them both in your config and specify them by name in your code.

The last two lines are exactly the same as what we have.

So really the only difference I see in your suggestion is the way that the configuration is wired in. Here's where your assumption comes in: you have assumed that the configuration is always in the same spot (ie. an app.config or web.config). There are no guarantees that this is the case.

Yes, we could probably change the interface so that it does search common configurations by default, and that is a suggestion that we're more than open to. As I said, this is v0.1.0 and it's just been unveiled. After using it, I'd be interested to see if you consider the configuration/wiring (which is still quite small, and a one-off task) painful.

We seem to be quibbling over one extra line of code, which ironically is substantially shorter than the comment that either of us has posted.

Having said that, we are always looking for ways to improve this kind of stuff, as I too hate unnecessarily verbose configuration. In our case, for version 0.1.0, we wanted to make sure the ability to configure and wire up in many different ways was available. In future revisions we'll no doubt look at home we can make this simpler.

With all this in mind, along with what I said in previous comments, how would you go about enabling this level of flexibility in the library without, as you put it, making it "drastically over-designed"?

[jallmann]

> You're right, we are making a few assumptions

Protip: build just as much as needed, and iterate as needed. You'll often find your early assumptions are not always the correct ones.

If you posted this saying, "Hey, this has been proven on a 20-node Riak deployment," then you would have a lot more credibility. Right now though, it seems like this is solving a Maserati problem for you.

> The first line of your code sample is making assumptions itself.

Read the rest of what I said. equark in this thread is also saying the same thing. Favor convention over configuration.

Here's another idea: dump the XML, or at least give us the option to bypass it and specify servers in code. The XML loader necessarily maps back to internal data structures, so why not cut it out completely? That is one-off; twenty lines of boilerplate is a PITA for quick projects, as are redundant configs sitting around uselessly.

I don't work with .NET (just offering up a critique) -- if that goes against the .NET orthodoxy, oh well. That'll be another reason I don't use it.

[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.