One of the big challenges of connecting directly to the existing thrift services is that there is a lot of logic imbedded in the Java client libraries that would have to be recreated. This includes things like finding tablets, managing multiple connections, handling tablet migration, handling read and write threads, etc. Sapan Shah was working on building a thrift proxy that would make native python bindings a lot simpler: see ACCUMULO-482. Maybe we can encourage him to continue to work on that if we all ask nicely.
Adam On Fri, Jul 27, 2012 at 9:01 AM, Jim Klucar <klu...@gmail.com> wrote: > I have a small proof of concept going. I'm still not sure what the > best way to do results paging is (i.e. your scan has a billion results > and won't fit in memory) My initial work is moving towards opening up > a HTTP/1.1 chunked-encoded stream like Twitter does for its streaming > API. The other thing I've been playing with are using websockets, but > that may restrict you to using JavaScript but I'm sure more client > side websocket libraries are coming. > > On Fri, Jul 27, 2012 at 8:50 AM, David Medinets > <david.medin...@gmail.com> wrote: > > Which reminds me. There was a discussion of using a REST interface on > > this list. Several people liked that approach because it would provide > > loose coupling between client and server. Also the client could use > > any language. At the time, nobody could spare the time to implement > > it. > > > > On Fri, Jul 27, 2012 at 7:37 AM, Jim Klucar <klu...@gmail.com> wrote: > >> Welcome Edmon. I think as far as a pure python library goes, you would > >> have to interface with the thrift protocols. My sense is that would be > >> discouraged at this point by the devs. I do have some experience with > >> it though, I made an attempt to interface to Accumulo with Node.js. It > >> turned into me writing the JavaScript version of TCompactProtocol, but > >> it's still incomplete at this point. I would vote for either > >> developing an officially supported Thrift interface, or an officially > >> supported REST interface using a JVM language. Then the language > >> barrier would be easier to overcome. > >> > >> Jim > >> > >> On Jul 27, 2012, at 7:19 AM, Edmon Begoli <ebeg...@gmail.com> wrote: > >> > >>> Hi David, > >>> > >>> I think that Jython is a good idea as at least a prototype or as a > bridge > >>> towards a full blown python library. > >>> > >>> It is probably not a good end state because most Python developers do > not > >>> want JVM and Java environment, and there is also performance overhead. > >>> > >>> Personally, I program in both languages, so I am good. > >>> > >>> Is there a particular protocol about contributing to accumulo project? > >>> On Jul 27, 2012 5:27 AM, "David Medinets" <david.medin...@gmail.com> > wrote: > >>> > >>>> On Thu, Jul 26, 2012 at 11:15 PM, Edmon Begoli <ebeg...@gmail.com> > wrote: > >>>>> 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. > >>>> > >>>> Welcome to the list. There are a lot of Python developers and I'm sure > >>>> that your client would be well received by the community. My own > >>>> advice is to write whatever is simplest (fastest to develop) and > >>>> iterate towards a more complex complete solution. > >>>> > >>>> Would jython be any use to provide python access to the existing Java > >>>> API without any rewrite or plumbing needed? > >>>> >
