One big yes. Couldn't agree more, and it is the direction the Java client is moving. I think the .net client is either there or on the way too. Ditto for ripple, the ruby client. Makes perfect sense.
On 8 Sep 2011, at 12:31, Greg Stein wrote: > Hey, all... > > After a couple comments on my recent work, and some archaeology on the > Python/Riak work over the past month... I've realized that I might > have a very different view of RiakTransport compared to what I'm > seeing in the current work. I figured it best to bring that to the > forefront and discuss: > > In my view, RiakTransport is used by RiakClient (and others) to "talk > to the Riak server". > > Some of the current work, and some proposed pull requests, seem to > take the position that a RiakTransport is "one connection to a server, > and the client should manage those". > > Needless to say, I'm in favor of my own position :-) ... I think it is > best to transfer *all* responsibility for talking to the server(s) to > the transport layer. I really don't think the client/bucket/object > layers should know anything about talking to the server(s). I'd like > to see the transport layer be told about all server(s) available, and > then it Just Works. > > I'm still a newbie with all this code, and need to keep plugging away > at the higher levels of functionality and compensation for problems. > I'd like to build up some code that contacts *one* given server, asks > for all of the ring servers, and then opens connections to those > servers. And then, it should (automatically) maintain client > connections based on what is happening with the Riak cluster. The > current (proposed) code manages connections to N servers, but has no > automatic add/remove based on changes in the cluster status. I think > this happens at a layer *just* above the actual transport. ie. > something tracks the changes in the ring status and its servers, and > transmits those changes into the transport layer, which alters its > communication with that cluster (regardless of whether that > communication is via HTTP or protobuf). > > > Okee doke. That's the end of my brain dump and future thoughts on the > transport and communication layer. I'd really like some feedback, > review, and thoughts. > > Thanks! > -g > > _______________________________________________ > 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
