Responses inline
On Thu, Aug 14, 2014 at 3:16 PM, Jonathan Hsieh <j...@cloudera.com> wrote: > I've always found working with the jruby part of the hbase shell jarring > because many of the hbase commands don't interact "natively" with jruby > constructs. Some work was done [1] [2] to make it a little better but it > is in that uncanny half-there half-not-there state. > > Yes, the tension caused by both trying to be a shell specific to HBase and IRB is part of what I'd like to get rid of. > On Thu, Aug 14, 2014 at 11:53 AM, Sean Busbey <bus...@cloudera.com> > wrote: > > > Hiya Folks! > > > > Right now, the HBase shell relies on an old version of JRuby (1.6, last > > released ~2 years ago) and a very old version of Ruby (1.8). > > > > I'd like to start working towards refactoring the shell. Updating some of > > our underlying libraries will make it easier to fix up some of our low > > hanging improvements (start up latency, utf8 support). > > > > This got me wondering about what the bounds of changing are (esp for > > master). > > > > 1) How common is making use of the fact that our shell is actually and > IRB > > session? Do we want to keep encouraging that for users? Could we change > the > > focus of the IRB version to be developers of HBase? Could we just make a > > HBase client gem and provide instructions for using it in IRB? > > > > > Most admin work and much "repair" work happens in the shell. > > If a gem makes it super easy for folks to get started with hbase that > sounds good. It does seem we'd need to haev a gem for each major version's > shelll to maintain compatibility if the gem is hosted separately from the > hbase release though, no? > > We could publish the gem as a part of our release process. Avro does this now for its Ruby support. We could also have a copy of the gem included in our binary release somewhere for local installs. > > > 2) However extensive our keeping IRB is, do we need to keep the same Ruby > > compatibility? Spanning Ruby 1.8 and 1.9 is a pain, but possible. (I know > > very few people still using 1.8 though) When Ruby 2 support lands > > supporting either of those won't be possible, because at that point JRuby > > will only support Ruby 2.1[1]. > > > > I have a slight preference for keeping modern. > Me too, but what does that mean for backports? Ruby 1.9 to 2.1 updates are supposedly smooth, but that's cold comfort to the ops person who discovers they have to update their hbase maintenance scripts because they land in a corner case. Ruby 1.8 -> later updates will be more painful. The pain is well documented[2], but only particularly relevant if people are relying on the "run a ruby script" functionality. > > > > 4) Lacking #2, what do we want to ensure keeps working the same? Existing > > shell commands in the exact form they have now? Table variables (as > opposed > > to setting a "current table" context for the shell session)? > > > > I have a preference for a more ruby-esque and more oo style of api for > the > shell. Today it is a frankenshell that is partially oo ruby style, and > partially procedural sql-shell-style. I'd even consider a new "user shell" > that is parallel to the current "hacker" shell, with the goal marginalizing > the current shell for low level repair work. > > > So the oo-style shell would be the "hacker shell" and the "user shell" would be a more traditional procedural shell? Or do you mean the reverse? I'm having trouble thinking of an example of a product with a non-procedural user facing shell. -- Sean
