Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E7F4BDEEE for ; Fri, 27 Jul 2012 16:44:03 +0000 (UTC) Received: (qmail 27641 invoked by uid 500); 27 Jul 2012 16:44:03 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 27617 invoked by uid 500); 27 Jul 2012 16:44:03 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 27609 invoked by uid 99); 27 Jul 2012 16:44:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2012 16:44:03 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.212.41] (HELO mail-vb0-f41.google.com) (209.85.212.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2012 16:43:57 +0000 Received: by vbkv13 with SMTP id v13so3331088vbk.0 for ; Fri, 27 Jul 2012 09:43:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=4Krefb71srQPJiDehB7x7/BLJa/4X8v2yuZRbkzfQHs=; b=KWlA6VlKhU6kpf5KBDTUMHG55sHmJ+6876KClj2EPHTKDSacItrr1hi8X0IhT8BPos zzfLyfR1ucS64ZibOpFfea4CwF3CmpiEqvGwNP4ck833S20e8kYu+a2uuYSY45ZOOxfy deNnc8ZaS9oOBiCKHvDu3KM4AgB7beWjbsdpLD1EZFa/fptmbW0XBM5wHU7DkgMyf+zE It6JNfu7iRfmby2KauPFiKCQmzwMoavP+DegRLTQ9Kajz/dIetlM8ablMDKLcbFo0rsy 9LxeMQriF+epf+IX/+rAnr+1698svICCgOau/bijs4CI7JcVVcu3757pEDLhu4aHSGPK fkkg== MIME-Version: 1.0 Received: by 10.52.29.176 with SMTP id l16mr2689967vdh.80.1343407417106; Fri, 27 Jul 2012 09:43:37 -0700 (PDT) Received: by 10.58.218.35 with HTTP; Fri, 27 Jul 2012 09:43:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Jul 2012 12:43:37 -0400 Message-ID: Subject: Re: Python client lib for Accumulo? From: Keith Turner To: dev@accumulo.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQndBuRV9u0idHTopYedRqjijpGvtCwMHpeiZGEIu1qISCEtePWwpYF7GRCDX5QTFP72pBV6 Does anyone know anything about Py4J? http://py4j.sourceforge.net/index.html I have never used it, but I am wondering if it would fit the bill? On Thu, Jul 26, 2012 at 11:15 PM, Edmon Begoli wrote: > Hi folks, > > I have just joined the list with the purpose of volunteering ideas, > design and development (and whatever else in lifecycle) > related to development of the Python client for accumulo. > > I have developed several RESTful clients and libraries before using > web.py and I am about to write another in Tornado > (http://www.tornadoweb.org/). > > I think that we could have a very nice, scalable and fast RESTful API > for Accumulo through Tornado. > > I would also like to develop pure Python library for accumulo similar > to HappyBase for HBase (https://github.com/wbolster/happybase). > > I work at Oak Ridge National Lab as a software engineer and tech. lead > on "big data" projects, > I can devote time, possibly bring more team members and I would be > happy to collaborate. Collaborations are welcome. > > I could certainly start a small wiki outlining the ideas and open them > for discussion. > > Regards and please advise, > Edmon > > > On Wed, May 2, 2012 at 11:31 AM, Jason Trost 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)? >> > > I would advise against rewriting the accumulo client code in python. > The code that finds tablets, retries in case of failure, parallelizes > read/writes, etc is fairly complex. I think the proxy option is best. > David and Eric mentioned REST and Thrift proxies. > > If we were to go to down the route of writing the client code in > another language, I think C++ with a C API would be the best option > because many language can easily bind to a C API. > >> 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