New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor WebAgg so it can communicate over another web server #2420
Conversation
@@ -1,6 +1,15 @@ | |||
""" | |||
Displays Agg images in the browser, with interactivity | |||
""" | |||
# The WebAgg backend is divided into two modules: | |||
# | |||
# - `backend_webagg_core.py` contains code necessary to embed a WebAgg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a certain je ne sais quoi missing here, namely the backend_webagg_core
code 😊
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doh! Commit has been amended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excuse my web-programming ignorance, but does this mean that it will be
possible to use WebAgg in a flask application served up via mod_wsgi in
apache? Asking for a friend...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If such a configuration supports websockets, yes, at least that's the idea. Due to my own web-programming ignorance, I won't guarantee it, but it would be great to have your friend's assistance working out any kinks or shortcomings to this approach.
I'm always a fan of those, though I fear that conclusion is a result of In principle I'm happy about this refactor, looks like a sane way of going about making the webagg solution better and more re-usable. |
Just tried out the example - the image is a little small in Firefox 17.6 (the status update is too big) and it seems much more laggy on localhost than it used to? |
@pelson: I've addressed your easy comments. As for the lag -- the timing is handled differently here than in the built-in server. I was trying to eliminate the dependence on having a scheduler in the server. Rather than scheduling redraws on idle, it just throttles the framerate. I tweaked it until it felt approximately the same for me, but I suspect it's a little to tied to how things work for me. I might experiment with trying to the scheduling on the Javascript side, which would also eliminate needing any special features in the server. |
Consider this experimental -- I have attached another approach that's completely timerless. It has the browser control when new frames should be fetched. It seems to perform much better locally. I haven't been able to tunnel into the office to simulate running over a slow internet link, but obviously we should ensure this works there, too. |
Thanks for the ping. @minrk has opened a PR that starts to implement IPython's new message spec for widgets. It is too early to start integration, but we would love to get your eyes on this soon. Overall the messaging is very similar to WebSockets - basically micro comm channels over one WebSocket. In terms of the requirements for this approach as @mdboom mentions anyone implementing a compliant server would need to have WebSocket support. This means you need to use an asynch framework such as tornado, twisted, gevent, etc. Flask will definitely not work. |
Ah, thanks for the clarification, Brian. Like I said, I am -- err, I mean |
Apache is the worst possible choice at this point. Apache does not know http://serverfault.com/questions/290121/configuring-apache2-to-proxy-websocket is looks like there are some work arounds, but I would probably not advise On Fri, Sep 13, 2013 at 10:54 AM, Benjamin Root notifications@github.comwrote:
Brian E. Granger |
I haven't tested it, but I think apache can proxy websockets now. |
over a server other than tornado.
sends a "draw" message to the browser. If the browser is not already waiting on another frame, it sends a "draw" message back to the server which then returns an actual frame. The nice thing about this approach is that it's completely timerless.
Refactor WebAgg so it can communicate over another web server
This is to address an immediate need we have at STScI, but probably needs some explanation.
We want to embed interactive WebAgg plots inside of a larger web application, but we don't necessarily want to serve the matplotlib websocket or http requests using tornado. We'd like to, instead, allow people to "bring their own webserver framework" to the party and have matplotlib communicate over that. (@stsci-sienkiew). The requirement for "websockets" specifically is still there.
This refactor should also make it easier to move to IPython's future widget communication pipeline down the road (@ellisonbg).
The easiest way to see how this works is to look at the
embedding_webagg.py
example, which embeds a plot in an example tornado application. I'm using tornado here for the example, even though that's what the "built-in" matplotlib server uses because it's really the only viable and mature Python tool for websockets I could find. It still makes for a useful example for how to embed in a larger Tornado application which might be doing many other things. I plan to write proper "how to" documentation for this, but thought I should hammer down the details first.As part of this, the Javascript API has all been moved under a single "mpl" namespace, so that it should be easier to import it alongside other Javascript libraries without fear of name clashes. If anyone is currently using the Javascript API to matplotlib to insert plots on their webpages this will break that. As this stuff is all still new and marked "experimental", I'd rather just break this now to get that right rather than carry around the baggage of not namespacing things correctly to begin with.
Cc: @pelson, @andreabedini (as people who have helped with and been interested in WebAgg).
@pelson: You may also enjoy that, ignoring the example, this is a "net deletion" pull request.