Deployment scenarios

[almarklein]

This issue serves to get a clearer picture on the scenarios of deployments of Flexx. To see what is needed implementation wise, to see what we might need to improve w.r.t. testing, etc. From this we should spin off issues for specific tasks.

Deployment scenarios

• 1 Deskop (Window, Linux, OS X, Raspberry Pi)
  • 1.1 Web server (clients connect via a browser). Handled via app.serve.
  • 1.2 App that serves via a browser on localhost (like Bokeh does). Handled via app.serve.
  • 1.3 Used in Jupyter notebook. app module has the logic to make this work.
  • 1.4 Used JupyterLab kernel. The app module should make this work. In this case Flexx should not bring its own PhosphorJS.
  • 1.5 Used in JupyterLab server (to extend JLab). The app module will probably handle this. Again, Flexx should not bring its own PhosphorJS.
  • 1.6 Desktop app running in CPython/Pypy. Using Firefox/XUL, Chrome app or Electron. If none of these runtimes is available, its probably ok to just raise an informative error.
  • 1.7 Frozen desktop app. No console. Needs Firefox/XUL, Chrome or Elecrtron to be available.
  • Ship XULRunner or Lightning in the app distribution --- Just Works.
  • To reduce size, can also ship without, but then we need a way to reliably communicate to the user that a runtime is needed. Possibly offer possibility to let Flexx download+install it.
• 2 Mobile devices (Android, IOS, Windows phone). Means we need to be able to package apps in the respective formats.
  • 2.1 Hosted app (i.e. have a webserver serve the app and on the phone make a "link". See W3C web manifest WIP.
  • 2.2 Static app (i.e. only exported JS+CSS) packaged into an "app".
  • 2.3 App with Python running. E.g. Via Kivi.

Browser support

We need to think what browsers we support, and what we do when Flexx runs on an unsupported browser (warn/err?). Browsers that should try to support are at least Firefox, Chrome, Edge, Safari?, and the native browsers for Android, Safari mobile and Edge mobile.

App, runtime, export

Anything in (2) as well as (1.7) is considered "exporting" an app. The logic for this should probably be implemented in a new subpackage.

Exporting mobile apps can probably be done with the help of existing tools like cordova and manifold.js. Some cross-overs are possible too: a Windows UWP runs on mobile and on desktop.

Fallback UI

For (1.7) we badly need a fallback way to communicate with the end user. Earlier ideas about this involved small lib based on OpenGL using GLFW to provide a window. An easier approach might be to use a simple (as in runs-anywhere, no Flexx-ui) web app --- since there is a browser anywhere. Maybe use .hta on Windows to make it look more like a dialog.

[Korijn]

No Electron or NW.js?

[almarklein]

My brain must have short-circuited: I wrote "Lightning", but I meant "Electron". Fixed it. And sure, NW.js falls in the same category.

[niki-sp]

Is PyQt or PySide suitable for 1.6 and 1.7? I can provide ~4 line ctypes based message dialog for Windows.

[almarklein]

Is PyQt or PySide suitable for 1.6 and 1.7?

I am not sure. The point is that the Qt webbrowser component might not be "modern" enough. It for sure won't work on PyQt4, I'd have to try for PyQt5 (see #167).

[almarklein]

I can provide ~4 line ctypes based message dialog for Windows.

I'd be very interested in those 4 lines :) We'd need a solutions for any platform, but that would be an awesome start.

[niki-sp]

def msg():
    from ctypes import windll
    MBW = windll.user32.MessageBoxW # unicode
    MBW(0, u'missing runtime', u'flexx', 16)

if __name__=='__main__':
    msg()

[Korijn]

With regard to scenario 1.7 I found this article and thought I'd share: https://www.fyears.org/2015/06/electron-as-gui-of-python-apps.html

[almarklein]

I think that blog post expresses very similar ideas as Flexx (and in particular flexx.webruntime). One difference is that in that post Electron spawns Python instead of the other way around.