I gave this a bit of thought too, and I think the easiest thing is to break the interface and wrap all instances of non-closable iterators in a closable one. That way we can delegate close down to the sources like deepCopy does. I think Josh created a ticket for this; if not I will so we don't derail this.
Also, in regards to the doodle thing, are we trying to set up like a cam show or something? Personally I don't see the issue with us just listing stuff here and having a discussion about it. On Tue, Jan 29, 2013 at 12:15 PM, Keith Turner <ke...@deenlo.com> wrote: > On Mon, Jan 28, 2013 at 7:12 PM, William Slacum > <wilhelm.von.cl...@accumulo.net> 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 >
