Bokeh, Vispy, and a common protocol to describe a scene

[Almar Klein]

Hey,

I just send a similar email to Bokeh-dev. I think this is also relevant
to the ideas of Cyrille and Nico, and for Vispy in general.

Some weeks ago I send an email with a link to a blog post on my thoughts
about Bokeh and Vispy. I hoped for a discussion about the idea to create
one library that has the benefits of both (and more). I now realize that
this is a terrible idea. I wrote an update here:

http://www.almarklein.org/future_vis2.html

The main idea (which has been proposed in similar forms) is to define a
standard for describing a visualization, and split existing
visualization libraries up in parts that are either a user API or a
rendering backend. I also think that this standard should describe
changes rather than state, which should make it work well w.r.t.
interactivity.

I think Bokeh and Vispy can play an important role in making something
like this happen, because they have much to gain from each-others
benefits, and also because Bokeh is basically already split in these two
parts.

Some examples/ideas of what we could do if we adopted such a standard:

* Making something like Cyrille+Nicos's Bokeh desktop backend would
become more trivial, plus it would also work for other user API's, e.g.
Matplotlib, if they can emit the protocol.
* We can forget about vector image output in Bokeh; users can just write
their visualization in Bokeh and use the MPL rendering backend.
* I'd be interested in making 3D visualization available in the browser,
but I don't think its a good idea to add it to Bokeh. Instead, this
could be implemented in a new rendering backend, which can be targeted
from the Vispy/Bokeh/MPL user API.
* A new user API like Holoviews can just target the standard and it
would work for all existing backends.

In summary: it would allow a richer visualization ecosystem, while
allowing users to stick to one user API.

Of course, different rendering backends support different functionality,
and we should think about how to deal with this in user API's. Also,
keeping the standard simple while allowing enough flexibility to
describe the various functionalities provided by the rendering backends
will be challenging. Having said that, even if we can make this work for
relatively simple plots, we have a lot to gain.

Regards,
Almar