Where would the proxy service run? I.e. how would it be deployed? As
a standalone server? Or bundled with each tablet server, etc?
I think this approach might be the easiest from a maintenance and
Is your proxy code published anywhere?
On Wed, May 2, 2012 at 11:58 AM, Eric Newton <[EMAIL PROTECTED]> wrote:
> Alternatively, you can create a Proxy service, which has a simple thrift
> API, which would use the java client library.
> This is ACCUMULO-482.
> I wrote one once, but it didn't get much use, and died due to lack of
> On Wed, May 2, 2012 at 11:31 AM, Jason Trost <[EMAIL PROTECTED]> wrote:
>> I noticed that there are no JIRAs for a python client
>> interface/lib/API for Accumulo. How involved would it be to develop
>> AND maintain a python client for Accumulo?
>> I realize that Jython can be used, but I am interested in a native
>> python lib that can be use more broadly with systems that don't work
>> with Jython.
>> In order to do this, it seems like we would need to:
>> 1. generate the python thrift bindings code (this is trivial)
>> 2. develop and maintain the python glue code to use the thrift code
>> and python zookeeper code to interact with the various accumulo
>> components. The current Java "glue" code looks quite long. How often
>> does this code change (in terms of new features or changes in
>> protocol, not bug fixes)?
>> Ideally the python API would be very similar to the Java interface
>> (Connector, Instance, Scanner, BatchScanner, BatchWriter, Key, Value,
>> Mutation, etc).
>> I guess what I am trying to get at is, does the Accumulo dev community
>> think it's worth the time and effort to develop and maintain a python
>> API? I personally think it is in order to help with adoption and
>> integration with other systems (Django is the primary system I want to
>> be able to use with it). I have some time to help this along, but I
>> don't think I have enough time to take this on alone. Is anyone else
>> interested in working together on this?