The things you like to see is also what I like to see, and it's what I have already done/is in progress.
The main part of the code that I feel is very messy is the fact that the transport completely depends on RiakBucket and RiakObject and RiakObject and RiakBucket does essentially nothing. I'm changing it so that the transports and what not could operate *independently* from the rest of the framework. If you have the time, take a look at my current source code and the docstrings. Any suggestions for future work will be appreciated. Cheers, Shuhao On Thu, Mar 15, 2012 at 2:08 PM, Armon Dadgar <armon.dad...@gmail.com> wrote: >> Message: 4 >> Date: Thu, 15 Mar 2012 11:13:03 -0400 >> From: Shuhao Wu <ad...@thekks.net> >> To: "Andrey V. Martyanov" <reald...@gmail.com> >> Cc: riak-users@lists.basho.com >> Subject: Re: riak-python-client2, a rewrite of the official client >> Message-ID: >> <CAP1J66d0VmsV0VKx+W849tE2KM8_S7wMW5ta=a9+munncxu...@mail.gmail.com > >> Content-Type: text/plain; charset=ISO-8859-1 >> >> I'm looked into just modifying and contributing to the existing library, and >> found several issues with it. Here's my main motivation for a rewrite: >> >> ? 1. The current structure riak-python-client is somewhat messy. Everything >> depends on each other. Just look at things like RiakLink and >> RiakIndexEntry. >> They're unnecessary and overcomplicates the code. Furthermore, if you look >> the transports, it's very much dependent on things like RiakObject, and >> RiakObject is pretty much nothing without the transport. It's almost like a >> circular dependency. So instead, I redesigned the transports to operate >> independently from things like RiakObject. To do this, simply modifying >> is not feasible and it will result in an almost complete rewrite anyway due >> to the dependencies problems I described. >> 2. There's a lot of "bloat" in the current riak-python-client. A simple >> example would be get_ and set_, as well as things like RiakLink and >> RiakIndexEntry. To get rid of those would pretty much require a rewrite as >> well. >> 3. Basho currently do not have a dedicated python developer working on this. >> I don't know this for sure but I think their resources, in terms >> of clients, >> go mainly to java, ruby and javascript, though that's just my observations. >> >> My primary goal of having a rewrite is hopefully simplify the code base as well >> as improve some aspects of the python client (such as not using deprecated >> functions such as apply) and (hopefully) increase the speed of the client. >> After examining the code (which I had to do while rewriting), I don't think >> simply modifying the current codebase could fix its issues (there are more >> issues then what I've stated), and I don't think it will take as long as people >> think. The current code base has about 4k lines of python and 0.5k lines of >> Erlang. In my client, a chunk of the code actually comes from the original >> client as they work with a few adaptations. >> >> As far as road map goes, I'm currently just rewriting all the functionalities >> provided by the current python client, and here's a list of things that Sean >> would like to see accomplished, which I will work on once I have all the >> functionalities of the current client complete: >> >> https://gist.github.com/1959278 >> >> I hope I've answered all the questions. If there is any more questions/comments, >> feel free to shoot it my way. >> >> Shuhao >> > > I agree that the Python client does need some work to clean it up, > and make it more idiomatic Python, but I'm not sure that a total rewrite > is necessary. > > Most of the abstractions are good, but they just need a bit of cleanup. > I think there is always a tendency to assume things are unnecessarily messy, > but once you get to rewriting it you end up running into the pain points that > drove those design decisions. > > If there is interest, we could just formulate a roadmap for the a set of breaking > changes to the existing client, and release it as a new version of the same project. > > Things I would like to see: > * Cleanup the transport interface > * RiakObject needs to be simplified > * Support a RiakJSONObject subclass which has the encoding logic that is inside RiakObject now > * Indexes need to be cleaned up > * MapReduce interfaces feel a bit dirty > * Much improved exception hierarchy > * RiakClient / RiakBucket interface needs to cleaned up > > Best Regards, > > Armon Dadgar > > > > > > _______________________________________________ > 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
