Only reason, I am resistant to the idea of not using the Bokeh server is that the existing features and scope of the project will be reduced. Since, all the plots and widgets are necessary in order to make the module usable, limiting the plots will not be good enough. Although I am open to contributions on this module even after GSoC, this is not valid statement for the proposal in GSoC.
I am fully aware with the probable issues of having the external library as core dependency. I can also imagine the module having independent frontend and backend. But is it worth rewriting the code that exist in Bokeh? |
In my opinion, no, if Bokeh does what we need and has its own community maintaining it, that's a better option than us trying to do it ourselves. And while I'm normally extremely hesitant to add more dependencies (I know Johnathan feels the same way), this is different as its an OOT module (at least for now).
If the determination is that Bokeh is a good fit, then by all means lets use it. The point I was trying to make (and the one that I think Marcus, Bastian, and Martin were making), is that it is preferable to architect this such that the interface to "the GNU Radio domain" is as agnostic to Bokeh as possible; we want to maximize the reusability of this effort down the road if for whatever reason we do something not-in-Bokeh.
Now, whether or not "Bokeh is a good fit" might still be up for debate, but I see Sebastian just responded on that topic.
Cheers,
Ben