Just let me know how and if we want to collaborate on this. As for RESTful API and paging, I think we could also look into OData-like protocol conventions that specify an API to scroll through the result set using 'skip' and 'top' in addition to opening the stream.
Edmon On Fri, Jul 27, 2012 at 9:01 AM, Jim Klucar <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> wrote: >>>> >>>>> On Thu, Jul 26, 2012 at 11:15 PM, Edmon Begoli <[email protected]> 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? >>>>>
