You guys have done an amazing job the library in terms of its capabilities. The docs are ok in most cases, but not always great. Though compared to a lot of other code I've seen you are way ahead :-)
I didn't mean to imply that it would be a good idea to do a carbon copy of the Erlang client library, but picking a language that's close enough would makes sense. .NET 4.0 has/had a bug in ConfigurationManager.GetSection() and that's exactly what your library uses, so your library gets that bug too :-) What you can't do with CorrugatedIron is something simple like this (preferred): var client = new RiakClient(port: 8098, transport: RiakClient.HttpTransport); client.Blah()... etc or at least something like that (to be close to the model you have): var cluster = RiakCluster.FromParams(port: 8098, transport: RiakClient.HttpTransport); var client = cluster.CreateClient(); The above statement (RiakCluster.FromParams(...) can optionally take an array of string to represent IP addresses for each node in the cluster defaulting to one node on the localhost if nothing is specified. As for XML... I personally try to stay away from it and most of my configs are in JSON even in .NET apps :-) By the way, you are using a good JSON library, which is pretty good at dealing with not always perfectly formatted JSON, so you can easily support JSON-based configs. Once again I'd like to say that you did a great job. Having inline API docs would be helpful. And having a simple way to create clients without having to deal with configs would be great (especially considering the .NET 4.0 bug you are stuck with). On Fri, Sep 30, 2011 at 5:05 PM, OJ Reeves <o...@buffered.io> wrote: > Hi Kyle, > Thanks for the feedback on our .NET client. I'm sorry to hear that you've > had issues with it. I'm very keen on hearing more about the issues and > details of the level of complexity you're struggling with so that Jeremiah > and I can work on making it better. > Configuration is one of those things that annoys everyone :) It's incredibly > hard to provide power, flexibility and simplicity all at the same time when > dealing with configuration. One thing that I think is important to bear in > mind is the target of the library is .NET. For many years this kind of > configuration has be done using app.config or web.config settings when > building .NET applications and that it something that we didn't want to fly > in the face of. While I do feel it's important to be able to configure the > library through code (in case you're using a REPL like FSI), I felt it was > more important to support the idiomatic .NET approach to configuration. Yes > that does come with a bit of XML configuration (which I also hate) but is in > many ways a necessary evil. > We had feedback on github and on HN from people indicating that they had > different preferences for the configuration and we sat up and listened. We > have since made some changes to the way you can configure CI, which can > completely do away with using the XML configuration if you so wish. This > does, however, mean you have to configure the client in code. If that's what > you decide to do you may have issues as you deploy to different > environments. I would still recommend using the XML configuration if you can > as managing that configuration for multiple environments is much easier. > YMMV :) > I'm not sure about the state of other clients, but CI supports talking to a > cluster both directly or via a proxy/loadbalancer and also has built-in > connection pooling. Having support for all of these things adds complexity. > This is the typical features vs simplicity tradeoff. Our feelings on the > topic were that we didn't want to limit .NET developers in their options. We > also felt that, at least in the short term, that .NET developers might not > want to deal with deploying a load balancer in front of their development > clusters, and hence built-in support for talking to a cluster was a must. > I'm fairly certain that there is at least one other client (for another > language) that doesn't have cluster/connection pooling support built-in and > the people in that community have asked for on a few occasions. A classic > case of damned if you do, damned if you don't :) > May I ask what issues in particular you have with getting the configuration > to work? Do you feel that the documentation on the topic is lacking? Are the > sample applications and code snippets not clear enough? Are the required > fields confusing in some way? Error handling is certainly something that we > can put a bit more work into. > As far as the API or object model is concerned, could you please elaborate > on what you found difficult or complicated? Is this another case of poor > documentation and bad examples? Do you feel that it doesn't do a good job of > being a .NET library and using the features of the languages where > appropriate? Jeremiah and I are obviously very keen to remove unnecessary > complexity and reduce the friction that people feel when using the lib, so > any detail here would be greatly appreciated. > Have you had a look at the Riak clients written in strongly-typed languages? > How do they compare for complexity? One of the "pains" when dealing with the > likes of .NET is dealing with types. The nature of the platform adds > constraints that languages like Ruby and dynamic languages like > Erlang/Python don't have. This is another thing that's hard to juggle while > building a Riak client. Any thoughts that you might have on this topic would > be well received. >> My suggestion for anybody trying to design a new client library is to >> mimic the API of >> the existing official libraries first and then add fancy features :-) > While this sounds sensible and nice in theory, in practice it's actually not > that simple (or the right approach) for a few reasons. Languages vary a > great deal and not just in syntax. Attempting to "port" an existing client > to a language doesn't do the target language justice and can often fly in > the face of convention for that language. I would be rather disturbed if I > saw a direct port of the Erlang API in the .NET world. Why? Because they're > vastly different beasts and the .NET version of the API would be horrible > and nothing like any other .NET API. Also, it just wouldn't be possible > given the nature of Erlang's dynamic typing vs .NET strong typing. In short: > a library should fit the technical ecosystem of the language it's written > in. That, in my humble opinion, would be more of a negative influence on the > uptake of the library than anything else. I feel that a library should > respect the platform it's written for. Happy to hear your thoughts on this > too! >> If it's too complicated (to understand and to setup) then >> people will simply give up and go somewhere else. > Absolutely agree, which is why I'm very keen to hear about the issues you've > had and to figure out how we can make them better. So far the uptake of CI > has been quite strong and the feedback very positive. I'm super keen to help > you so that you become one of the happy users :) > One last question: are you aware of any other .NET clients which have a > similar set of features? I can only find two and they haven't been touched > for over a year. > Thanks again for the feedback, I look forward to hearing more and working > with you to make your experience with CI much better! > All the best. > OJ > > On 1 October 2011 04:14, Kyle Quest <kcq.li...@gmail.com> wrote: >> >> I looked at a lot of different Riak libraries in different languages >> for my work with Riak and CorrugatedIron was one of them. This gave me >> an opportunity to compare how each of them worked. CorrugatedIron was >> one of the more complicated ones :-) It was also one of the hardest to >> make it work because of the app config design (the library generated >> exception when it tried to load the config data). My suggestion for >> anybody trying to design a new client library is to mimic the API of >> the existing official libraries first and then add fancy features :-) >> This will help the adoption. If it's too complicated (to understand >> and to setup) then people will simply give up and go somewhere else. >> >> On Fri, Sep 30, 2011 at 10:45 AM, Jeremiah Peschka >> <jeremiah.pesc...@gmail.com> wrote: >> > Thanks. I can't take all the credit/blame - OJ Reeves has written >> > massive amounts of code, too. >> > >> > We're aware that many people like to complain about our use of config >> > files. When you write a piece of software, you make the choice between >> > shipping software or adding more features. We chose to ship CorrugatedIron >> > and see then what people liked and what they didn't like. >> > >> > People didn't like our use of .NET's crusty old config system that they >> > even created a github issue about it: >> > https://github.com/DistributedNonsense/CorrugatedIron/issues/4 >> > >> > We hear you and will be moving to get this out as soon as we can after >> > we get the Riak 1.0 feature compatibility ironed out. >> > >> > Is our use of .NET configuration files blocking adoption of >> > CorrugatedIron in your organization? >> > --- >> > Jeremiah Peschka - Founder, Brent Ozar PLF, LLC >> > Microsoft SQL Server MVP >> > >> > On Sep 30, 2011, at 1:40 PM, Kyle Quest wrote: >> > >> >> Jeremiah, really nice job on CorrugatedIron! Some of it is a bit too >> >> over-engineered and more complicated than it has to be. For example, >> >> you can't just create a RiakClient object and interact with Riak (like >> >> you can do with the official Riak client libraries)... To create a >> >> RiakClient (in CorrugatedIron) you need to have a RiakCluster object >> >> to pass to the RiakClient object constructor. And you can't easily >> >> create a RiakCluster object either. You can only create it from a >> >> config section (there's no way to explicitly provide the config values >> >> directly in the API). Not every app uses .NET app config files and >> >> it's also not uncommon for the app config code to cause exceptions >> >> because it can be brittle... >> >> >> >> On Thu, Sep 22, 2011 at 3:33 PM, Jeremiah Peschka >> >> <jeremiah.pesc...@gmail.com> wrote: >> >>> I just finished up v0.1.3 of CorrugatedIron, everyone's favorite .NET >> >>> 4.0 Riak client. There is no new functionality in this release, just a >> >>> fix >> >>> from Matthew Whitfield: >> >>> https://github.com/DistributedNonsense/CorrugatedIron/issues/18 >> >>> >> >>> Thanks Matt for helping us make CorrugatedIron better! >> >>> >> >>> Binaries have been pushed to NuGet >> >>> (http://nuget.org/List/Packages/CorrugatedIron) and source is available >> >>> on >> >>> github >> >>> (https://github.com/DistributedNonsense/CorrugatedIron/commit/e9c0af10465176f117bbbf04724087063f9b7fd2) >> >>> >> >>> Enjoy! >> >>> >> >>> --- >> >>> Jeremiah Peschka - Founder, Brent Ozar PLF, LLC >> >>> Microsoft SQL Server MVP >> >>> >> >>> >> >>> _______________________________________________ >> >>> riak-users mailing list >> >>> riak-users@lists.basho.com >> >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >>> >> > >> > >> >> _______________________________________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > -- > > OJ Reeves > http://buffered.io/ > _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
