The proxy would be co-located with the tablet servers, but as a standalone service.
The old proxy code is has not been published, and is way too old to be useful. It would be easier and cleaner to start from scratch. -Eric On Wed, May 2, 2012 at 12:26 PM, Jason Trost <[email protected]> wrote: > Eric, > > 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 > integration standpoint. > > Is your proxy code published anywhere? > > --Jason > > 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 > > attention. > > > > -Eric > > > > 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? > >> > >> Thanks, > >> > >> --Jason > >> >
