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 5D12DF000 for ; Tue, 29 Jan 2013 17:34:15 +0000 (UTC) Received: (qmail 83792 invoked by uid 500); 29 Jan 2013 17:34:15 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 83752 invoked by uid 500); 29 Jan 2013 17:34:15 -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 83744 invoked by uid 99); 29 Jan 2013 17:34:15 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 17:34:15 +0000 Received: from localhost (HELO mail-lb0-f179.google.com) (127.0.0.1) (smtp-auth username ctubbsii, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 17:34:14 +0000 Received: by mail-lb0-f179.google.com with SMTP id j14so1056865lbo.10 for ; Tue, 29 Jan 2013 09:34:12 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.145.37 with SMTP id sr5mr1879455lab.33.1359480852459; Tue, 29 Jan 2013 09:34:12 -0800 (PST) Received: by 10.114.1.111 with HTTP; Tue, 29 Jan 2013 09:34:12 -0800 (PST) In-Reply-To: References: <5106EED8.1080600@gmail.com> Date: Tue, 29 Jan 2013 12:34:12 -0500 Message-ID: Subject: Re: Accumulo 1.6 and beyond feature summit From: Christopher To: dev@accumulo.apache.org Content-Type: multipart/alternative; boundary=e89a8f2346854a2f7b04d470cd0b --e89a8f2346854a2f7b04d470cd0b Content-Type: text/plain; charset=ISO-8859-1 Features I'd like to see: 1. Better user experience for configuration: separate, *non-xml* configuration files for separate services, and for clients. 2. Separate packaging for separate services (tservers, monitor, master, trace), especially for RPMs and DEBs to make provisioning easier. 3. A suite of command-line utilities based on the shell's commands, that work in Bash, rather than be restricted to the limitations of the shell to issue these commands. 4. Provide a script maintained and supported by the community to provision an Accumulo cloud instance in EC2 or OpenStack. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jan 29, 2013 at 12:15 PM, Keith Turner wrote: > On Mon, Jan 28, 2013 at 7:12 PM, William Slacum > wrote: > > I'd like to see: > > > > - Data triggers on insertion > > - REST interface for looking up ranges of keys > > - A DSL or some other interpreted language for crafting iterators > > - there's the clojure iterator, but something like python (via jython) > or > > javascript (via rhino) would be more adoptable > > - Adding a clean up hook to iterators > > I was thinking about this. If we added a close() method to the SKVI > interface then it would break existing iterators. Another option > would be to support closing iterators that implement Closeable. So if > in iterators is an intstanceof Closeable then the framework could > close it when its finished with the iterator. I wish there had been > a 1.5 ticket for this, I think it would have been fairly simple to > implement. > > > - Allowing iterators to launch connections to other services (caching, > > other tservers) to retrieve or write data > > - Merging of the batch scanner and scanner implementations > > - a batch scanner with 1 thread have the same behavior as a scanner > > - scanners have a close() method on them > > - Adding some builder interface for creating and introspecting iterator > > stacks > > - Clients being able to scan to specific keys using the scan command > --e89a8f2346854a2f7b04d470cd0b--