-Re: updating shell functionality
Jesse Yates 2011-11-23, 21:02
Yeah, the jvm repls are getting pretty sweet. However, that is going to be
a bunch of work to just get back the same functionality we have now. I
don't think there is a really compelling reason to make the switch - we
don't get a ton more functionality and it isn't significantly easier to
make changes add functionality (at least, after initially thinking about
The unit tests actually are pretty nice as it stands now - they are well
encapsulated and look really clean in the ruby syntax.
There are some issues where it feels like people made a kludge of certain
parts, without realizing what was happening because it was just one more
thing. There has been a lot of added functionality recently making the
previous shell that much more awkward. I would be open to doing a rewrite
if we really get that much more out of it - do you have any compelling
reasons besides it makes the translation a little easier (which isn't that
bad right now)? Yeah its time for a bit of redesign, but lets not throw the
baby out with the bath water.
Another idea that has come up is that often times you want to work in the
context of a table, rather than entering it for every command. Accumulo
does this where you pick the table context to work in. Sometimes its really
simple and nice and other times its a pain when you forget to make the
I was thinking we could have the option to drop into a table context
(switching into a TabledShell?), but still keep around a lot of the current
functionality. This has implications for the current shell paradigm of
"verb, table, row, etc." (as stack put it), which for some of the current
functionality (eg. coprocessors, attributes, possibly some of the security)
feels a bit forced and awkward.
On Tue, Nov 22, 2011 at 11:15 AM, Elliott Clark <[EMAIL PROTECTED]> wrote:
> So a little more on the crazy idea side.
> Java type repls are starting to get more love and are a little more
> developed than they were when jruby was first used. Is is time to start
> considering a more java repl (scala, clojure, groovy, et al) ? All of
> those would have less of a translation of java -> repl command, would be
> more easily testable with maven/junit and a Ci server. Shouldn't be too
> hard to get either scala or groovy shell's to work hbase env and load the
> right classes. Then auto complete should do the rest for making the
> transition pretty easy. In addition it would be nice for encoding issues to
> go away.
> I agree that moving away from using strings for args seems like the way to
> go. So any love to the shell would be appreciated.
> On Tue, Nov 22, 2011 at 10:48 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > Interesting idea.
> > See the following for reference:
> > On Tue, Nov 22, 2011 at 10:34 AM, Jesse Yates <[EMAIL PROTECTED]
> > >wrote:
> > > Hey all,
> > >
> > > I'm trying to take some time to figure out the right way to do support
> > > future 'pluggable' features/extensions to modifying tables. Specially,
> > I'm
> > > thinking about the 'alter' command, but in the future, this model could
> > be
> > > applied to other facets of the shell.
> > >
> > > In the easiest, and hackiest) way, we could just take in the full
> > > name to call and then lookup the java class, but I like Gary's comment
> > > from HBASE-4605
> > > (Constraints) <https://issues.apache.org/jira/browse/HBASE-4605>:
> > >
> > > "3. provide a extensions dir for the shell:
> > >
> > > - extensions drop a simple jruby scriptlet in a file in the dir (say
> > > lib/ruby/hbase/ext)
> > > - the scriptlet does some simple registration of the available
> > > methods/commands
> > > - the shell code loads all files"