I want to explain the issue that @enzo raises regarding htmlwidgets. Both R interpreters support a variety of html widgets, because they use the "knitr" package, which acts as a bridge for many interactive vis packages.
Neither, however, supports the "htmlwidgets" R package. The reason is that "htmlwidgets" visualizations use javascript and css that has indirect dependencies, which knitr does not handle. When people use the htmlwidgets package in R, they typically use a package called "rmarkdown." rmarkdown wraps knitr and passes content through pandoc, which imports the indirect dependencies. I looked, but have not been able to find an external library that could handle the indirect dependencies, other than pandoc. The issue with pandoc is that it is a heavy package that writes a lot of temp files to disc, and the performance impact is significant. If there is demand for this, I did have it working at one point. I also spent a good amount of time trying to implement code to handle the indirect dependencies in R or scala. It's a highly non-trivial problem. There is also a third kind of R interactive vis package, packages based on the "shiny" R package. shiny widgets have to be able to communicate with a running R instance through websockets. Since R is not multi-threaded, the same R process that communicates with Zeppelin can't be used as a shiny server. We could try to spawn a separate process, but then how would we keep a consistent environment among notebook cells? The potential payoff from supporting shiny is, I think, pretty huge. But finding a way to support it is challenging. My intention has been, after the interpreter is merged, to reach out to the authors of shiny, and see if there is an interest in collaborating to solve the problem. On Monday, February 29, 2016 01:04:47 PM enzo wrote: > As a keen R user I tried both branches, but I couldn’t make work Charles' > version (maybe my mistake). I found some issue on Amos' version (mainly > about charting), reported on his github page (he has suggested to test more > extensively and report after merge - fair enough). > > In conclusion I do not have sound enough elements to judge on which one is > better. As I’m in favour of competition as a general principle, taking into > account that they seem to be close to the finishing line I would suggest to > merge each one and let users decide: I concur with Eran. > > It would be useful (just to avoid similar occurrences in the future) to > understand why we arrived here though. How is it possible that a > fundamental pr as R interpreter takes so long to be integrated? I would > humbly suggest for the future to give better treatment to the big hitting > functionalities. Clearly the more a ‘big’ functionality is delayed, the > more will be deemed attractive to develop alternative versions (some time > better versions, some time equally useful). > > Another consideration is the over present issue of graphics. From an R > standpoint, due to the extreme richness of its graphic offering, so far I > found that no notebook is entirely satisfactory: for example the growing > family of htmlwidgets are badly (or not) displayed in many cases. It would > certainly benefit the community to invest time and activities on perfecting > these issues, but so be it. > > > Enzo > e...@smartinsightsfromdata.com > > > On 29 Feb 2016, at 12:36, Eran Witkon <eranwit...@gmail.com> wrote: > > > > I think we should ask ourselves what is the guiding principle here, for > > example, if in the future I want to create yet another JDBC interpreter or > > Flink interpreter, should I only extend the one that already exist or can > > I > > create my own and let the user community decide? realistically I don't > > think we can control where people invest their time and contribution and > > as > > long as it has no licencing issues and align with other project guidance > > it > > should be up to the users to decide. > > > > Eran W > > > > On Mon, Feb 29, 2016 at 2:13 PM DuyHai Doan <doanduy...@gmail.com> wrote: > >> Hello Alexander > >> > >> My opinion is no one, unless being an expert with R, is able to judge the > >> quality of both contributions apart from the authors themselves. So let's > >> make them work together to merge 2 PR into a good one. Those PR, > >> especially the #208 has been there for a while and it's high time they > >> get > >> merged so the community can move on. > >> > >> Unless there are R experts in the Zeppelin community and so they should > >> speak to give their own opinions. > >> > >> My 2 cents > >> > >> Duy Hai DOAN > >> > >> On Mon, Feb 29, 2016 at 1:04 PM, Alexander Bezzubov <b...@apache.org> > >> > >> wrote: > >>> Hi fellow Zeppelin community members, > >>> > >>> as you know, we have 2 contributions for ZEPPELIN-156 > >>> <https://issues.apache.org/jira/browse/ZEPPELIN-156> AKA R > >>> <https://github.com/apache/incubator-zeppelin/pull/208> interpreter > >>> <https://github.com/apache/incubator-zeppelin/pull/702>. > >>> Both have merit, so wearing my PPMC hat, I'd like to suggest us to make > >>> a > >>> decision, how we move forward with it avoiding user confusion. > >>> > >>> Here is what we can do: > >>> - a. pick only one of those and merge it > >>> - b. ask authors of both of them to collaborate together and come up > >> > >> with > >> > >>> one > >>> - c. merge each, as soon as it's ready and let users\maintainers decide > >>> which one is best at the end > >>> > >>> This is not an official VOTE (which is possible to arrange, but is > >>> rather > >>> bad way to build a consensus). > >>> > >>> It is a discussion, aimed to see if we all, as community, can build a > >>> consensus together cooperatively - meaning, *everyone compromises > >>> something *and* there are no really strong opinions against the final > >>> plan*. > >>> > >>> I specifically DO NOT ask which one is better, have more features, etc, > >>> etc, etc. > >>> What I ask for are opinions on a community way of reconciling this > >>> situation and moving project forward together. > >>> > >>> What do you think? > >>> > >>> -- > >>> Kind regards, > >>> Alexander.
