java/groovy APIs for external widgets

[scottdraves]

@maartenbreddels suggests this and it sounds like a good idea.
eg: ipyleaflet, pythreejs, ipyvolume.

[maartenbreddels]

@SylvainCorlay @jasongrout @vidartf
It would be nice to see how this works to get a jleaflet/jvolume, and from there maybe vidar can see how to autogenerate code from pythreejs for jvm languages.

@scottdraves
I'm assuming one only needs to target 1 jvm language (Java OR Scala OR Clojure) and get the other for free right?

[scottdraves]

If we do java then we get them all, but scala has its own types so it can be improved by having a wrapper. see https://github.com/twosigma/beakerx/tree/master/kernel/scala/src/main/scala/com/twosigma/beakerx/scala/chart

[scottdraves]

Maarten volunteered to allow a subdirectory in the ipyvolume repository with the API.
then with a https://github.com/twosigma/beakerx/blob/master/jitpack.yml
file at the top level, the jars would get published in a way that would be easy to import to beakerx with the %classpath add mvn magic.

[vidartf]

pythreejs is using autogeneration for code, so that might be possible.

Another project that might be relevant is https://github.com/vidartf/widget-gen/. It allows for generating widget stubs based on the serialization format that would be used. It doesn't translate any logic, but if your kernel side widgets are only for data input it should be easy to sync all the kernel side definitions.

[vidartf]

PS: widget-gen is able to parse python widget definitions with traits as a source for auto-generation.

[maartenbreddels]

I think that would be a good idea, that saves me trouble of maintaining the boilerplate part.

[vidartf]

@scottdraves Do you think you could hash out some sort of template-like structure for a widget definition in java/scala? If i have such a starting point, I can incorporate support for it in widget-gen.

[scottdraves]

Wow cool widget-gen will help a lot.
Yea let's do it :)

[scottdraves]

progress

[maartenbreddels]

Progress indeed! Nice to see, willl try this out really soon.

[scottdraves]

pythreejs starting to work now too:

[scottdraves]

[vidartf]

@scottdraves Neat! Let me know if there are any issues that are particularly tricky, and I'll do my best to help. I'm also curious to have a look at the code, to see how you consume the exposed "interfaces". Would you mind pointing at where the code resides?

[scottdraves]

thanks! here it is: https://github.com/twosigma/pythreejs/pull/2
next up: computing the mesh in groovy instead of JS.

[maartenbreddels]

I'm ok with having jvolume in the ipyvolume repo, I'm just wondering if it is a good idea, and what about pythreejs/jthreejs and ipywebrtc/jwebrtc ?
@vidartf any ideas?

[SylvainCorlay]

For the bqplot / xplot, pythreejs / xthreejs, ipywebrtc/ xwebrtc, we have been going with separate repositories for now. Would you not want to split ipyvolume itself eventually?

[maartenbreddels]

I'm not sure what are the advantages, since all the packages (js,py,jvm,c++) or so closely related. For a monorepo, any API change can be done for all languages in 1 commit, and the repo will (or should) always be in a consistent stage.
With multiple repos, it's difficult to know which version/commits belong or even work together, especially when different versioning schemes are used.
But I'm not sure I want to do something that is non-standard, if nobody likes that approach.

[SylvainCorlay]

The only advantage that I see would be that a front-end extension can be updated, and the bindings for e.g. Python / C++ / JVM can upgrade at their own pace (pinning the front-end requirement...)

Also, it is generally simpler to look at a repo, and immediately identify the directory structure of a python / C++ package, and where things are.

[scottdraves]

For a monorepo, any API change can be done for all languages in 1 commit, and the repo will (or should) always be in a consistent stage.

i think this is a very strong advantage.

[bhugueney]

Thanks for working on this ! Is ipyleaflet still considered ? I'd love to be able to use it from Java.