Well... I'm looking at some work on transports/http.py and that host/port is passed around *as if* there is a possibility/reason to vary the values. But when you get down to it, .http_request can just use ._host and ._port, and we can eliminate these spurious parameters from thought.
In particular, I'd like a transport that manages N persistent connections, so requests will be using a "connection" parameter rather than a host/port combination. This is why I ask about API guarantees. My assumption is that transports/transport.py defines the only API that must be preserved, and all other methods are open to change... but I wanted to ask for confirmation first. Cheers, -g On Mon, Sep 5, 2011 at 10:44, Jonathan Langevin <jlange...@loomlearning.com>wrote: > Re: 2. Not that I disagree with removing those values, but is there some > additional benefit that you're expecting by removing the static values? > (just curious)* > > <http://www.loomlearning.com/> > Jonathan Langevin > Systems Administrator > Loom Inc. > Wilmington, NC: (910) 241-0433 - jlange...@loomlearning.com - > www.loomlearning.com - Skype: intel352 > * > > > On Mon, Sep 5, 2011 at 8:47 AM, Greg Stein <gst...@gmail.com> wrote: > >> I've got a couple more questions: >> >> 1. Why is "pycurl" used in the http transport? What benefits does it >> offer? Based on reading the code, I see no additional functionality, >> so I don't understand why this complexity exists. I'd like to submit a >> changeset that just removes it, but would like to understand if there >> is a reason/history for using pycurl. >> >> 2. What is the policy around the API on the transports? As a concrete >> example, I'd like to remove the HOST and PORT parameters from >> RiakHttpTransport.http_request() (and remove them from the return >> values of build_rest_path()). The parameters are always self._host and >> self._port. Given the semantics of the transport, these would *never* >> change... even by third party code that might call into these >> functions. Would removing these parameters pose problems w.r.t API >> stability guarantees? >> >> >> 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
