Hey Greg,
Let me just clarify for the connection manager. I don't know what's going
on there, so I'm not trying to write the code there. The current code is
temporary as I want to test out the concept of moving transports to an
independent layer. I'm not sure how connection manager should work. So
On Thu, Mar 15, 2012 at 14:08, Armon Dadgar wrote:
>> Message: 4
>> Date: Thu, 15 Mar 2012 11:13:03 -0400
>> From: Shuhao Wu
>> To: "Andrey V. Martyanov"
>> Cc: riak-users@lists.basho.com
>> Subject: Re: riak-python-client2, a rewrite of the offic
On Thu, Mar 15, 2012 at 11:13, Shuhao Wu wrote:
>...
> Erlang. In my client, a chunk of the code actually comes from the original
> client as they work with a few adaptations.
Yes, I noticed that you retain transports/connection.py, but why did
you strip out all the comments?! That is definitely
On Thu, Mar 15, 2012 at 2:15 PM, Shuhao Wu wrote:
> 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 a
at 2:08 PM, Armon Dadgar
wrote:
>> Message: 4
>> Date: Thu, 15 Mar 2012 11:13:03 -0400
>> From: Shuhao Wu
>> To: "Andrey V. Martyanov"
>> Cc: riak-users@lists.basho.com
>> Subject: Re: riak-python-client2, a rewrite of the official client
>> Message
> Message: 4
> Date: Thu, 15 Mar 2012 11:13:03 -0400
> From: Shuhao Wu
> To: "Andrey V. Martyanov"
> Cc: riak-users@lists.basho.com
> Subject: Re: riak-python-client2, a rewrite of the official client
> Message-ID:
>
> Content-Type: text/plain; charset
I'm not considering replacing it just yet. It's a work in progress. If it
gets support, awesome. Otherwise, there still can be continued development
to hunt down bugs and so forth. We are still keeping the old library
around, it's just that now you have options with this well designed newer
library
Shuhao,
It seems reasonable.
sloccount reported the following:
Total Physical Source Lines of Code (SLOC) = 3,661
python:3160 (86.32%)
erlang: 501 (13.68%)
Not too much.
But. The current version of riak python client is used in many projects.
Formspring, for example, contribut
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
RiakInde
Hi Shuhao,
What is the reason to create a fork? What is your primary goal? Do you have
any particular plans or roadmap? It would be very helpful.
Best regards,
Andrey Mart
On Thu, Mar 15, 2012 at 5:30 AM, Shuhao Wu wrote:
> That would be most appreciated.
>
> I just completed a very bare minim
Hi Shuhao,
On 15 Mar 2012, at 00:30, Shuhao Wu wrote:
> That would be most appreciated.
>
> I just completed a very bare minimum higher level API that's similar to the
> current Python client. However, there's still a lot of work to be done. Once
> again, I'm just one lone student working in
That would be most appreciated.
I just completed a very bare minimum higher level API that's similar to the
current Python client. However, there's still a lot of work to be done.
Once again, I'm just one lone student working in my spare time and I can't
possibly think of everything. If we want to
This is great Shuhao!
I've had problems using the python client using multiple threads with protocol
buffers. The exact same multithreaded code works fine with http protocol. So,
any attention you can give to the pbc transport would be hugely appreciated.
Good luck! Can't wait to give your new
Hey guys,
I've been working with riak and python for the past couple of months, and
I'm at the point where I'm ready to completely reimplement
riak-python-client. So.. I did/started. The project is hosted on github and
under the same apache 2 license as the original client.
https://github.com/ult
14 matches
Mail list logo
