Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of ebegoli@gmail.com designates
 209.85.220.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKoQnDU4OSgHK61NmkKon4MZsOUqe0M99hykShfnSOgb5EFjTw@mail.gmail.com>
References: 
 <CAGj+YsfA2GWWXHEN6heKnJ_9ReL5ur=G0ww6e9cS9OnRPv5Lwg@mail.gmail.com>
 <CAOiJXP5S1BsbHDNnh1YKfx-2v9+UVNbuUFYY++SGmbiU8Fmerg@mail.gmail.com>
 <CAGj+YsdZshJjdF6CjyemcqgZueOLNYMhYfMgsY7X5Md2ueY21Q@mail.gmail.com>
 <-3652101023413683974@unknownmsgid>
 <CAOiJXP7awdBzEzXRFoAeM7=vnv6uf+ZE74wqe+CguxG+pBha9Q@mail.gmail.com>
 <CAKoQnDU4OSgHK61NmkKon4MZsOUqe0M99hykShfnSOgb5EFjTw@mail.gmail.com>
From: Edmon Begoli <ebegoli@gmail.com>
Date: Fri, 27 Jul 2012 09:06:50 -0400
Message-ID: 
 <CAGj+Ysfpkxa9OAX4R5QxR_ib1yzrn-11MGE_R-L2WBy+dC2NPQ@mail.gmail.com>
Subject: Re: Python client lib for Accumulo?
To: dev@accumulo.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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 <klucar@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.medinets@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 <klucar@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 <ebegoli@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.medinets@gmail.com> wrote:
>>>>
>>>>> On Thu, Jul 26, 2012 at 11:15 PM, Edmon Begoli <ebegoli@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?
>>>>>