[python] en remplacement de [php]

Version imprimable

05/07/2011, 13h32
pfeuh

[python] en remplacement de [php]

Salut,

j'ai fait une page web qui affiche des données de capteurs. Pour l'instant, ces données sont envoyées via une requête ajax par un script php qui les simule sur le serveur. Pour lire réellement ces données, j'ouvre un port série en python et je lis les capteurs. La suite logique serait de remplacer par un script python le script php du serveur qui reçoit la requête ajax et y répond. Ça semble réalisable ou pas? Quelqu'un aurait une piste?

A+

Pfeuh
05/07/2011, 14h05
mont29

Bien sûr, que c’est réalisable :D

Tu pourrais en rester au python pur, mais je te conseillerais plutôt un framework léger (comprendre*: pas django ou, pire encore, zope –*ce serait utiliser le Charles de Gaulle pour partir à la pêche à la sardine*!), genre par exemple cherrypy, qui devrait te permettre de réaliser un petit serveur de ce genre en quelques heures ;) …
05/07/2011, 14h59
pfeuh
Merci pour ta réponse. On se rejoint au sujet de Django et de Zope :ccool: Je viens d'installer le module cherrypy (que je ne connaissais pas) et de lancer le hello world après avoir ouvert avec mon navigateur la page http://localhost:8080/ ;
Code:

1 2 3 4 5 6 7 8 import cherrypy class HelloWorld(object): def index(self): return "Hello World!" index.exposed = True cherrypy.quickstart(HelloWorld())
j'ai l'erreur suivante:
Code:

1 2 3 4 Traceback (most recent call last): File "hello.py", line 8, in <module> cherrypy.quickstart(HelloWorld()) AttributeError: 'module' object has no attribute 'quickstart'
Ca me parait logique, ou alors il y a un déclic que j'aurai dû ressentir mais qui n'est pas venu. :? Chose étrange, la page http://localhost:8080/ me sort un 'Access Error: 404 -- Not Found'... Bref, ça démarre mal... :roll:

Citation:

Envoyé par mont29

Tu pourrais en rester au python pur

j'avoue que ce serait la solution qui m'arrangerait le plus: Un serveur en attente de requête, parsage, exécution et pour finir envoi du résultat. Peut-être quelque chose qui importerait liburl2?
05/07/2011, 15h17
pfeuh

Citation:

Envoyé par pfeuh

Peut-être quelque chose qui importerait liburl2?

:? Je crois que j'ai écrit une énormité... urllib2... ca remplace un client, pas un serveur?

j'ai trouvé une piste assez intéressante ici Si quelqu'un a une autre idée...
05/07/2011, 17h08
mont29

Ben, c’est normal que t’aies une 404, vu que cherrypy démarre pas (il faut d’abord lancer cherrypy avant d’ouvrir la page sur ton navigateur, au fait*!)… Par contre, quickstart existe bien dans le module cherrypy, t’as installé quelle version*???

Après, oui, tu peux utiliser SimpleHTTPServer, mais ça va te faire plus de travail, et surtout, ce sera bien plus difficile à faire évoluer… :? C’est toi qui vois*!
08/07/2011, 09h44
pfeuh

J'ai finalement réussi à m'en sortir avec des moyens simples à ma portée. J'ai une table mysql de valeurs. Cette table est mise à jour toutes les secondes par python (qui lit les capteurs) et elle est consultée par des requêtes ajax/php toutes les secondes.

Ça marche, mais ce n'ai pas ce que j'aurai voulu faire, c'est à dire répondre directement aux requêtes ajax en python. Je pense que cherrypy peut le faire, mais les quelques heures de développement nécessaires dont tu parlais risquent chez moi de se transformer en quelques jours.

A+

Pfeuh
09/07/2011, 16h19
wiztricks

Salut,

Citation:

Envoyé par pfeuh

J'ai finalement réussi à m'en sortir avec des moyens simples à ma portée. J'ai une table mysql de valeurs. Cette table est mise à jour toutes les secondes par python (qui lit les capteurs) et elle est consultée par des requêtes ajax/php toutes les secondes.

De toutes façons, je ne vois pas trop comment cela pourrait être autrement. Difficile de lier l'interrogation des capteurs aux requêtes AJAX! Il faut un tampon au milieu et dé corréler les deux.

Citation:

Ça marche, mais ce n'ai pas ce que j'aurai voulu faire, c'est à dire répondre directement aux requêtes ajax en python. Je pense que cherrypy peut le faire, mais les quelques heures de développement nécessaires dont tu parlais risquent chez moi de se transformer en quelques jours.

Une requête AJAX est d'abord une requête HTTP qui sera traité "côté serveur" par du code Python ou autre. Dans votre cas, "il suffit"(*) de lire
la BDD et de remonter les enregistrements au format JSON par exemple.

(*) Le client pourrait émettre un HTTP GET sur l'url http://host/capteur/id pour récupérer le dernier enregistrement sur le capteur "id". Comme c'est assez "cablé" vous n'avez besoin que d'un serveur WSGI.
Note: Ca fait pas un serveur Web, juste la réponse au http GET de lecture sur l'URL http://host/capteur/id.
- W
11/07/2011, 15h02
pfeuh

Citation:

Envoyé par wiztricks

De toutes façons, je ne vois pas trop comment cela pourrait être autrement. Difficile de lier l'interrogation des capteurs aux requêtes AJAX! Il faut un tampon au milieu et dé corréler les deux.

Comme ce serait le même programme qui lit les capteurs et répond aux requêtes ajax, le tampon pourrait être un simple dictionnaire en ram. Du coup, je peux éliminer la base de données qui me semble (mais je peux me tromper) pénalisante au niveau de la charge.
11/07/2011, 20h32
wiztricks

Salut,

Citation:

Envoyé par pfeuh

Comme ce serait le même programme qui lit les capteurs et répond aux requêtes ajax, le tampon pourrait être un simple dictionnaire en ram. Du coup, je peux éliminer la base de données qui me semble (mais je peux me tromper) pénalisante au niveau de la charge.

Certes, mais en général on stocke les valeurs sorties des capteurs pour avoir des tendances et un éventuel historique. Côte stockage, voir rrdtools par exemple. Et ce "en général" est peut être décalé par rapport à vos besoins.
Si la base de donnée vous ennuie et que vous ne voulez avoir que la dernière mesure, pourquoi ne pas poser le dictionnaire dans un fichier au format JSON?
- W
12/07/2011, 09h12
pfeuh

Citation:

Envoyé par wiztricks

en général on stocke les valeurs sorties des capteurs pour avoir des tendances et un éventuel historique.

Là, ce n'est pas le but. Il s'agit simplement d'avoir une idée des valeurs à un endroit assez distant, il n'y a aucune intention de log ou d'historique.

Citation:

Envoyé par wiztricks

Si la base de donnée vous ennuie et que vous ne voulez avoir que la dernière mesure, pourquoi ne pas poser le dictionnaire dans un fichier au format JSON?
- W

Pour la même raison que la suppression de la base de données... Si on peux faire sans fichier, pourquoi se pénaliser avec un fichier? Pourquoi le programme devrait stocker ces enregistrements dans un fichier et relire ce fichier à chaque requête Ajax, au lieu de travailler directement dans un dictionnaire en mémoire? Il y a peut-être une raison qui m'échappe?

Merci pour le lien sur RRDtool, je ne connaissais pas. Ca me servira sûrement pour un autre projet.
12/07/2011, 20h51
wiztricks

Salut,

Citation:

Envoyé par pfeuh

Pour la même raison que la suppression de la base de données... Si on peux faire sans fichier, pourquoi se pénaliser avec un fichier? Pourquoi le programme devrait stocker ces enregistrements dans un fichier et relire ce fichier à chaque requête Ajax, au lieu de travailler directement dans un dictionnaire en mémoire? Il y a peut-être une raison qui m'échappe?

"Travailler directement dans un dictionnaire en mémoire" suppose une mécanique genre section globale ou threads pour y accéder.
Sur le papier c'est sympa, mais çà augmente la cohésion entre les différentes activités: threads http qui supportent AJAX et celle qui mettent à jour les infos récupérées sur les capteurs.

Dans la pratique passer par la mémoire n'est indispensable que pour aller "vite"... Mais "vite" est "relatif" et si vous passez par des consultations par des requêtes AJAX... c'est assez "lent".

Vous pouvez très bien imaginer une lecture des capteurs toutes les 10s. mettant à jour un ou des fichiers.
Côté requête AJAX vous lisez un dictionnaire qui ne sera relu qu'après mise à jour du fichier par la lecture des capteurs.

Puis vous vous dites, ok... mais la réponse à la requête AJAX pourrait inclure des informations de cache ou un GET conditionnel.
=> le dictionnaire est devenu une sorte de cache avec des états distribués dans le browser, le serveur,...

Vous pouvez traiter beaucoup de requêtes rapidement sans avoir à trop coupler les différentes activités.

Je ne dis pas que c'est mieux, juste que çà peut être "plus simple" à réaliser.
- W