On 24 July 2012 15:53, Sean Cribbs <s...@basho.com> wrote: > > I've begun adding Riak 1.2-related features to the Python client. As I am > doing so, I am reminded about how much technical debt exists in the client, > as discussed at length previously on Github and this mailing list. Because I > know some of you are using the client in production or as a component of > another library, I'd like to assess what risks there are in removing or > changing certain features.
Yay! :-D > Remove all the set_r/get_r-style methods for quorums. Instead, RiakBucket > will have custom object-properties for these that let you set the > corresponding quorums in the bucket-properties, but will not be the sort of > cascading-preference behavior that it is currently. If you want to change a > quorum when fetching, storing, or deleting a key, you can pass it with > keyword arguments to the appropriate method. Sounds good. I always thought there were too many of these. > Remove the edge-case-ridden ConnectionManager for a pair of resource pools > for each protocol, like what is available in the Ruby client. Access to a > connection would be granted via a 'with' statement, naturally, and the > protocol selected would be based on the stated preference of the user, or on > whether the transport supports the given feature. For example, stats would > always use HTTP. We could also take this opportunity to add error-sensitive > host selection and automatic retries to the client. I've never taken the time to properly understand what the ConnectionManager actually does, but I really like the idea of something a little more flexible about which transport backends to use. However, I'd like to take this a step further, as described below. > Merge the RiakSearch class into the RiakClient class and push some of its > functionality down into the connection classes. Sounds good. > I intend to make the Python client ready for the 1.2 release without these > refactorings, but I would greatly appreciate your feedback before starting > the above items. Cool. So, on to my grandiose plans for the future of the Python Riak client. We're currently using a combination of this client and Riakasaurus, which is a Twisted-based client library that we maintain. Riakasaurus is based (indirectly) on a previous version of the Python client, but is different enough that it's impossible to pull in upstream changes directly. The main reason for the divergence is that the Python client assumes blocking network I/O operations that will return when they have the required data, while Twisted uses an asynchronous callback-based I/O mechanism. I think it would be possible to restructure the Python client somewhat to decouple the higher-level operations from the lower-level network operations in a way that would let us switch between Twisted-style async I/O and more traditional blocking I/O. This would probably be a fairly invasive change in some ways, but shouldn't have any noticeable impact on the external API. I'm hoping it'll make the ConnectionManager replacement cleaner and more flexible, but I don't have a good enough mental model of the system to be sure. As the person proposing this, I'm happy to put some effort into hacking up a prototype to see if this is actually a workable idea and to do the bulk of the implementation work if it is -- it'll save on a bunch of Riakasaurus maintenance in the future if we can pull it off. I'm proposing some pretty drastic surgery to the existing codebase, so I'd like to know if other people (especially Sean) think it's a good idea before I sink too much time into it. Thanks, --J _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
