Back-end WSGI integrado para la aplicación de escritorio Python que usa webkit

Question

Descargo de responsabilidad: no estoy muy familiarizado con ninguna de las cosas mencionadas en el título de la pregunta.

¿Sería posible usar un control de navegador (como Webkit) como frontend para una aplicación WSGI (usando un marco como Flask) sin iniciar un servidor WSGI local?

Básicamente, las solicitudes y respuestas son administradas por una capa intermedia entre la interfaz de usuario HTML y el backend de WSGI. Un URI determinado podría significar "Local", por ejemplo "local: //" o algo similar, y se enrutará a la aplicación WSGI incorporada con todos los encabezados originales, etc.

Perderá las funciones que un WSGI normal servidor a menos que lo implemente usted mismo o de alguna manera incruste un servidor que también se puede utilizar a través de una API en lugar de solicitudes HTTP reales.

Ahora que lo pienso, este es el único requisito real: Un servidor WSGI que se puede llamar mediante una API y no solo solicitudes HTTP reales.

Sé que la utilidad de esto es cuestionable (y tal vez ni siquiera tiene sentido). Mi pregunta es si esto es posible?

EDIT: Aquí hay otra manera de decirlo:

quiero un solo código base para ser tanto una aplicación web y una aplicación de escritorio, utilizando una interfaz HTML y un motor de Python. No quiero ejecutar un servidor en ningún puerto para la aplicación de escritorio. ¿Cuál es la forma más fácil de lograr esto?

Answer 1

Hoy he visto exactamente lo que está pidiendo: una forma de llamar a WSGI a través de una API sin realmente conectarse a través de la red. Sin embargo, no debería ser tan difícil.

En una nota lateral, es posible que desee ver PySide, de particular interés para usted puede ser la capacidad de vincular elementos de pitón con eventos DOM, por lo que si solo busca activar código python que es una ruta aún más corta .

Si proporciona más detalles sobre lo que espera lograr, podríamos llamarlo por usted.

Answer 2

En teoría es posible escribir su propio WSGI container que implemente una API completa y lo adapte a WSGI. flup podría traer algo de inspiración.

Answer 3

Reviviendo esto, ya que estamos enfrentando el mismo problema y estamos a punto de ampliar las cosas desde una única vista/widget a toda la aplicación.

Lo que hice fue establecer simplemente la URL base a algo donde sirvo contenido estático, ya partir de un archivo de QRC eso es fácil:

html = jinjatemplate.render(...) 
self._mainFrame.setHtml(html.decode('utf-8'), Qt.QUrl('qrc:///Orsync/html/')) 

Para la comunicación, nuestra HTML utiliza AJAX sobre jQuery para la mayoría de las cosas . Se podría concluir que, en una capa que, o bien lo hace $.post(...) o api.post(...) así:

self._mainFrame.addToJavaScriptWindowObject('api', self._webapi) 

que había necesidad de decodificar la URL y crear una solicitud de objeto a sí mismo, pero tal vez eso no es demasiado difícil de hacer? En la actualidad, utilizamos muy pocas URL (que se asignan directamente a los objetos/funciones de python), por lo que es fácil realizar el mapeo nosotros mismos.

Los datos que se devuelven se envían utilizando QMainFrame.evaluateJavaScript(...), ya sea como una llamada Qt directa o como un conjunto de líneas de código captadas usando $.getScript(...) (que solo evalúa el código recibido).

Actualmente estoy reconstruyendo un poco las cosas usando CherryPy, y mapea urls -> objetos de Python directamente, así que espero que haya algo que ganar con eso.

De lo contrario, me gustaría poder ejecutar QWebKit sobre las canalizaciones con nombre o algo similarmente localizado y no un tcp-socket. :)