Re: Adding Angular API to non-Spark interpreters

[DuyHai Doan]

All interpreters can leverage the AngularObjectRegistry.

The Cassandra interpreter does this here:
https://github.com/apache/zeppelin/blob/master/cassandra/src/main/scala/org/apache/zeppelin/cassandra/InterpreterLogic.scala#L316-L356

On Fri, Dec 9, 2016 at 10:45 PM, Goodman, Alexander (398K) <
alexander.good...@jpl.nasa.gov> wrote:

> Hi Randy,
>
> The main thing you are probably looking for is the AngularObjectRegistry
> class (https://github.com/apache/zeppelin/blob/master/zeppelin-int
> erpreter/src/main/java/org/apache/zeppelin/display/AngularOb
> jectRegistry.java). One of the fields of InterpreterContext is an instance
> of this class, so you could in theory just place the interpreter result
> into the registry here:
>
> https://github.com/apache/zeppelin/blob/master/zeppelin-
> interpreter/src/main/java/org/apache/zeppelin/interpreter/remote/
> RemoteInterpreterServer.java#L474
>
> While I agree that we should try to better expose the angular API to more
> interpreters, there are a few problems with your approach.
>
> First, you may noticed that a recent change was made to interpreter results
> (https://github.com/apache/zeppelin/pull/1658). This ultimately makes the
> feature you are asking for considerably more complicated to implement
> correctly since you have just one paragraphID but potentially multiple
> results with different types, and you'll only want a certain part of the
> result to get bound to the registry.
>
> Also, I am not sure if enforcing this automatically would be a good idea
> considering that only certain types of results are useful to store as
> AngularObjects. If this gets applied to every paragraph automatically I
> could see this potentially leading to some churn within the system, but I
> can't say for sure. Either way, I think this should be something like a per
> paragraph feature which can be toggled via a UI option.
>
> I think this is a good discussion to have, since I do agree that leveraging
> this feature to other interpreters would lead to great advances in
> Zeppelin's visualization capabilities. Perhaps we should take some time to
> discuss other ideas for making this happen?
>
> Thanks,
> Alex
>
> On Fri, Dec 9, 2016 at 12:27 PM, Randy Gelhausen 
> wrote:
>
> > I created https://issues.apache.org/jira/browse/ZEPPELIN-1782 with
> > additional detail for this feature request.
> >
> > I looked into the InterpreterContext classes, but am not sure how to
> > implement this. Any suggestions from others?
> >
> > Thanks in advance,
> > -Randy
> >
> > On 2016-11-24 18:31 (-0500), Randy Gelhausen  wrote:
> > > I often need to visualize data in other ways than supported by the out
> > of>
> > > the box charts. I can do this with Angular notes and custom JavaScript,
> > but>
> > > Spark is the only interpreter with capability to set Angular
> variables.>
> > >
> > > Could it be possible to automatically expose all interpreter results
> as>
> > > Angular variables using the paragraph ID as the variable name?>
> > >
> > > This would greatly improve the custom viz capabilities for Zeppelin
> > without>
> > > requiring developers of each interpreter to integrate with Zeppelin's>
> > > Angular API.>
> > >
> >
>
>
>
> --
> Alex Goodman
> Data Scientist I
> Science Data Modeling and Computing (398K)
> Jet Propulsion Laboratory
> California Institute of Technology
> Tel: +1-818-354-6012
>

Re: Adding Angular API to non-Spark interpreters

[Goodman, Alexander (398K)]

Hi Randy,

The main thing you are probably looking for is the AngularObjectRegistry
class (https://github.com/apache/zeppelin/blob/master/zeppelin-int
erpreter/src/main/java/org/apache/zeppelin/display/AngularOb
jectRegistry.java). One of the fields of InterpreterContext is an instance
of this class, so you could in theory just place the interpreter result
into the registry here:

https://github.com/apache/zeppelin/blob/master/zeppelin-
interpreter/src/main/java/org/apache/zeppelin/interpreter/remote/
RemoteInterpreterServer.java#L474

While I agree that we should try to better expose the angular API to more
interpreters, there are a few problems with your approach.

First, you may noticed that a recent change was made to interpreter results
(https://github.com/apache/zeppelin/pull/1658). This ultimately makes the
feature you are asking for considerably more complicated to implement
correctly since you have just one paragraphID but potentially multiple
results with different types, and you'll only want a certain part of the
result to get bound to the registry.

Also, I am not sure if enforcing this automatically would be a good idea
considering that only certain types of results are useful to store as
AngularObjects. If this gets applied to every paragraph automatically I
could see this potentially leading to some churn within the system, but I
can't say for sure. Either way, I think this should be something like a per
paragraph feature which can be toggled via a UI option.

I think this is a good discussion to have, since I do agree that leveraging
this feature to other interpreters would lead to great advances in
Zeppelin's visualization capabilities. Perhaps we should take some time to
discuss other ideas for making this happen?

Thanks,
Alex

On Fri, Dec 9, 2016 at 12:27 PM, Randy Gelhausen  wrote:

> I created https://issues.apache.org/jira/browse/ZEPPELIN-1782 with
> additional detail for this feature request.
>
> I looked into the InterpreterContext classes, but am not sure how to
> implement this. Any suggestions from others?
>
> Thanks in advance,
> -Randy
>
> On 2016-11-24 18:31 (-0500), Randy Gelhausen  wrote:
> > I often need to visualize data in other ways than supported by the out
> of>
> > the box charts. I can do this with Angular notes and custom JavaScript,
> but>
> > Spark is the only interpreter with capability to set Angular variables.>
> >
> > Could it be possible to automatically expose all interpreter results as>
> > Angular variables using the paragraph ID as the variable name?>
> >
> > This would greatly improve the custom viz capabilities for Zeppelin
> without>
> > requiring developers of each interpreter to integrate with Zeppelin's>
> > Angular API.>
> >
>



-- 
Alex Goodman
Data Scientist I
Science Data Modeling and Computing (398K)
Jet Propulsion Laboratory
California Institute of Technology
Tel: +1-818-354-6012

Re: Adding Angular API to non-Spark interpreters

[Randy Gelhausen]

I created https://issues.apache.org/jira/browse/ZEPPELIN-1782 with
additional detail for this feature request.

I looked into the InterpreterContext classes, but am not sure how to
implement this. Any suggestions from others?

Thanks in advance,
-Randy

On 2016-11-24 18:31 (-0500), Randy Gelhausen  wrote:
> I often need to visualize data in other ways than supported by the out
of>
> the box charts. I can do this with Angular notes and custom JavaScript,
but>
> Spark is the only interpreter with capability to set Angular variables.>
>
> Could it be possible to automatically expose all interpreter results as>
> Angular variables using the paragraph ID as the variable name?>
>
> This would greatly improve the custom viz capabilities for Zeppelin
without>
> requiring developers of each interpreter to integrate with Zeppelin's>
> Angular API.>
>

Adding Angular API to non-Spark interpreters

[Randy Gelhausen]

I often need to visualize data in other ways than supported by the out of
the box charts. I can do this with Angular notes and custom JavaScript, but
Spark is the only interpreter with capability to set Angular variables.

Could it be possible to automatically expose all interpreter results as
Angular variables using the paragraph ID as the variable name?

This would greatly improve the custom viz capabilities for Zeppelin without
requiring developers of each interpreter to integrate with Zeppelin's
Angular API.