Hi all,
I've been putting more thought into this problem, particularly in
contrast to the "client manages N transport [connections]." I believe
that the latter is not very workable given the variance in underlying
transports. Not enough information is available to the client to
manage the connecti
On my 'newhttp' branch, the ConnectionManager class handles all
connections to the server(s) for the transports (many connections to
many servers). The transport can worry about what goes onto the wire,
and the CM worries about the underlying connections.
Today, there are multiple transports, each
I own the pull request that adds (very basic) pooling logic to the
Riak client. I left Transports alone (each is a single connection) and
decided to have pools be another class you pick just like transport.
This allows you instantly use any pooling logic (never remove down
servers, delete down serv
Yup, agreed. I can certainly see use-cases where a client may have
particular knowledge about data/server locality, and wants to open
connections to *just* those servers. The transports that I am
advocating open connections to servers described by one layer higher.
That layer could say "all Riak se
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 rec
I like the idea of RiakTransport as you describe it. It opens the door to
other potential underlying transports and isolating a client from knowledge
of those (websockets, tcp, zeromq messaging come to mind). I'm not
suggesting that RIAK will ever support these transports by this comment,
however.
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 di
