Formalize the communication protocol (no more eval)

[almarklein]

Right now, for some stuff the Python side sends JS over that is eval'ed at the client. I'd like to move to a more formal protocol, and have an explicit entry point for this, to allow using the JS side of Flexx from other systems. In other words, all JS widgets (as written in PyScript) can be used using a completely independent Python library. Or a Julia library, or a JS library...

One use-case I have in mind that if there were a visualization library based on Flexx, it could be compatible with a standardized visualization protocol.

Also, maybe the protocol should be binary, to send data more efficiently, e.g. for visualization. A downside of that is that exported apps would need base64 encoding, or can we put the list of commands in an external (binary) resource?

[almarklein]

(this might be a possible approach for Bokeh to do its widgets)

[almarklein]

There has been an occurance where Chrome would block JS in a flexx app, probably because of the eval that we use. Using a formalized protocol should get rid of that.

[almarklein]

mmm... now that I think of it, that's not entirely true. Model classes that are defined after the page has been served will be dynamically defined, using eval. Well, at least eval would be used way less.

[almarklein]

Related to #143

[almarklein]

Mmm, it seems that eval() would be a good way to load modules dynamically, and still have them show up as "files" in the debugger, using //# sourceURL=hello.js.

Eval is not necesarily evil, as long as you do it in a way that does not allow misuse. Since the server sends the source over a websocket, I don't think this is a problem. Arguments about performance don't matter these days.

We might want to look at https://developer.chrome.com/extensions/contentSecurityPolicy to prevent the Chrome browser from blocking eval, though.

[Korijn]

Did you also see this variant on the same scheme? Serving a JS file that has //@ sourceURL=foo.js at the beginning will also show it in the devtools.

http://stackoverflow.com/a/18007439/552379

[almarklein]

Had a look at the protocol during some of the late app refactoring. Most commands consist of a command and then a string. There are a few exceptions of commands that have more "arguments", but they can safely be space-splitted. Commands that are just strings also have advantages, e.g. in exported notebooks. Therefore, I chose to leave it as is. The commands can still be formalized, though I don't think there is much need while its only our Py and our JS talking to eachother.