Discussion :

[_skip]

Bonjour,
J'ai découvert python depuis peu et il m'intéresse pour un projet client-serveur sur lequel la rapidité de développement joue un grand rôle.
J'ai déjà vu que tout était plus ou moins OK pour la partie client, par contre pour le serveur je suis un peu moins sûr.

En gros j'ai trois contraintes pour la partie serveur :

1) Avoir une interface web d'administration, ça j'ai vu que c'était bon

2) Gérer manuellement des requêtes Get/Post pour créer une sorte de webservice en JSon maison. Pour cela j'aurai besoin de quelque chose d'assez bas niveau qui ressemble à une servlet java.

3) Pouvoir partager une structure de donnée entre les utilisateurs. Je m'explique, j'aimerai au démarrage de mon serveur pouvoir charger certaines ressources (des index spécialement) et pouvoir les utiliser librement dans chaque requête, sans être obligé de persister et recharger tout ça. C'est une chose qui se fait sur les serveurs d'applications .Net ou java mais pas en PHP par exemple.

Si vous pouvez me renseigner sur les possibilités dont je dispose. Je suis preneur.

[wiztricks]

3) Pouvoir partager une structure de donnée entre les utilisateurs. Je m'explique, j'aimerai au démarrage de mon serveur pouvoir charger certaines ressources (des index spécialement) et pouvoir les utiliser librement dans chaque requête, sans être obligé de persister et recharger tout ça. C'est une chose qui se fait sur les serveurs d'applications .Net ou java mais pas en PHP par exemple.

Plusieurs choses.
1 - Statefull signifie a priori la possibilité de gérer un contexte "session" pour préserver l'état entre plusieurs requêtes http issues d'un même client: beaker fait cela très bien,
2 - Ce que vous racontez est plus construction d'un cache global aux requetes utilisateurs qui permettrait d'accélérer nombre de chose, memcached fait cela aussi.

Pylons, Django, Turbogears intègrent ces biblitohèques/frameworks et permettent de réaliser cela. Après vous pouvez aussi refaire, construire à partir des composants élémentaires ces fonctions là.
- W

[_skip]

Plusieurs choses.
1 - Statefull signifie a priori la possibilité de gérer un contexte "session" pour préserver l'état entre plusieurs requêtes http issues d'un même client: beaker fait cela très bien,
2 - Ce que vous racontez est plus construction d'un cache global aux requetes utilisateurs qui permettrait d'accélérer nombre de chose, memcached fait cela aussi.

Pylons, Django, Turbogears intègrent ces biblitohèques/frameworks et permettent de réaliser cela. Après vous pouvez aussi refaire, construire à partir des composants élémentaires ces fonctions là.
- W

Merci pour la réponse!

En fait ce que je cherche à faire c'est un poil plus complexe qu'un cache puisque je suis censé pouvoir altérer la structure de donnée plus ou moins à chaque requête au moyen de méthodes synchronisées.

Pour simplifier au mieux, c'est un peu une sorte de file d'attente globale dans laquelle des utilisateurs se connectent, réservent un "ticket" dans une file, s'en dégagent (ou se font éjecter), changent de place suivant les priorités etc... J'ai besoin pour cela d'une structure de données vraiment de scope application et pas quelque chose qui vit et meure simplement dans un cycle request ou quelque chose qui survit uniquement dans un contexte session utilisateur.

Les serveurs d'application java permettent cela, par contre pas un serveur comme apache à ma connaissance.

Après recherche, j'ai cru voir que certains serveurs comme cherryPy sont en fait des applications qui *intègrent* un web server et donc me permettraient théoriquement de faire ce que je demande.

Je patauge un peu mais je vais essayer de creuser cette voie... Je reste ouvert à toutes suggestions.

[wiztricks]

J'ai besoin pour cela d'une structure de données vraiment de scope application et pas quelque chose qui vit et meure simplement dans un cycle request ou quelque chose qui survit uniquement dans un contexte session utilisateur.

C'est ce que je range dans les "caches globaux" qui peuvent être des structures de type KV (des __dict__ en Python) avec un backing store "global".
C'est pas parce qu'on va utiliser cela pour mettre des données en cache qu'ils sont réduit à "cacher" quoi que ce soit: on met ce qu'on veut dedans.
- W

[thierry.chich]

En dehors de potentiels aspects "performance", c'est quoi l'apport par rapport au stockage dans une bête base de donnée (qui aura le mérite de ne pas effacer les valeurs après avoir relancé le serveur web )?

[wiztricks]

En dehors de potentiels aspects "performance", c'est quoi l'apport par rapport au stockage dans une bête base de donnée (qui aura le mérite de ne pas effacer les valeurs après avoir relancé le serveur web )?

A défaut d'utiliser des frameworks tels que Django, TurboGears ou Pylons qui proposent un contexte session et donc des fonctionnalités "similaires" à celle qu'on trouverait dans Tomcat...
J'ai compris la question comme "comment ajouter un contexte session à un pur serveur HTTP qui est 'stateless' par essence voire comment définir un contexte 'global' à l'ensemble des sessions".

Dans cette affaire là, il y a trois dimensions:
- des données partagées entre différents threads/process qui pourront être intégrées de façon simple dans un programme Python - qui ne voit que des objets,
- une éventuelle "persistance" qu'on pourra réaliser comme on veut en fonction de....
- le mapping entre les données "persistées" et les objets "Python".

Rien qu'un SGDB classique ne sache faire, mais bien sûr les performances seront ce qui feront préférer une mécanique à d'autre.
- W

[_skip]

Le fonctionnement typique d'un site web peut être résumé à ceci : une requête http arrive, le serveur fait un certain nombre d'opérations et recrache un document html. Ensuite il persiste la session utilisateur et ne fait plus rien.
5 min plus tard une autre requête arrive, le serveur se réveille, recharge la session utilisateur refait quelques requêtes, recrache un document html et point final.
Ce qu'il faut retenir, c'est qu'entre les requêtes il se passe absolument rien. Dans le cas de php c'est quasiment un process qu'Apache exécute et qui se termine à la fin du cycle HTTP ce qui ne permet pas de conserver un état en mémoire et éventuellement travailler dessus.

Ce que permet un serveur d'application java comme tomcat, c'est justement de faire tourner une application en permanence. Une requête HTTP déclenche alors simplement un thread dans le serveur qui va invoquer une fonction (java en l'occurrence) de l'application, cette fonction va pouvoir interagir sur ladite application : accéder à des objets actuellement en mémoire (avec toutes les précautions de synchronisation) en lecture ou écriture, déclencher des traitements asychrones sur le serveur etc...

A titre d'exemple : Imaginez simplement une application dans laquelle une interface web est disponible pour lancer des commandes qui mettent 5 min à s'exécuter.
Vous lancez la requête http correspondant à l'action, la fonction côté serveur insère une tâche dans la file et vous retourne un gentil message "votre tâche est en cours de traitement".

Votre cycle http est fini, pourtant le serveur est bien vivant et bosse, il vous envoie un mail 5 min plus tard pour dire qu'il a fini son boulot et que vous pouvez accéder au résultat d'une URL ou d'un no de ticket X.

C'est ça que j'aimerai être certain de pouvoir faire. Une application avec une sorte de console de commande web en django ou autre, ainsi que quelques autres URL maisons qui serviraient de points d'entrée à un webservice travaillant lui aussi sur les données de mon application.

[wiztricks]

C'est ça que j'aimerai être certain de pouvoir faire. Une application avec une sorte de console de commande web en django ou autre, ainsi que quelques autres URL maisons qui serviraient de points d'entrée à un webservice travaillant lui aussi sur les données de mon application.

Comprenez que Java/Python ne sont que des langages de programmation.
Si vous voulez construire ces fonctionnalités à partir de requêtes HTTP, vous devez construire des frameworks similaires à Tomcat, Django, Pylons.

Note: Django Book ou Pylons Book vous montrent comment réaliser cela.
Si vous voulez faire du J2EE like, vous avez Zope qui fait çà aussi.

Ce qui est important là dedans c'est que le langage de programmation utilisé devient "relatif" par rapport au savoir et aux savoir faires à acquérir côté "framework" utilisé.
- W

[_skip]

Comprenez que Java/Python ne sont que des langages de programmation.
Si vous voulez construire ces fonctionnalités à partir de requêtes HTTP, vous devez construire des frameworks similaires à Tomcat, Django, Pylons.

Note: Django Book ou Pylons Book vous montrent comment réaliser cela.
Si vous voulez faire du J2EE like, vous avez Zope qui fait çà aussi.

Ce qui est important là dedans c'est que le langage de programmation utilisé devient "relatif" par rapport au savoir et aux savoir faires à acquérir côté "framework" utilisé.
- W

Merci,

Faites-vous pas de soucis je sais dissocier l'aspect langage de l'aspect framework.

Mais pour ce cas, c'est l'existence de briques logicielles adaptées qui fait qu'un langage est un bon choix ou non pour ce type d'application. Pour certains ce sera très simple (java grâce aux serveurs tomcat, jboss, jetty etc.. et .Net grâce à IIS), pour d'autres ça reviendra à se fabriquer son serveur à la main à partir d'un socket.

J'aurai du formuler ma question autrement et changer "est-ce que c'est possible?" par "est-ce que ça se fait?".

Je vais jeter un oeil du côté de Zope, j'y suis déjà allé mais il me semble que c'était pas super clair ce que ça permettait.
Merci pour ces pointeurs

[thierry.chich]

A titre d'exemple : Imaginez simplement une application dans laquelle une interface web est disponible pour lancer des commandes qui mettent 5 min à s'exécuter.
Vous lancez la requête http correspondant à l'action, la fonction côté serveur insère une tâche dans la file et vous retourne un gentil message "votre tâche est en cours de traitement".

Votre cycle http est fini, pourtant le serveur est bien vivant et bosse, il vous envoie un mail 5 min plus tard pour dire qu'il a fini son boulot et que vous pouvez accéder au résultat d'une URL ou d'un no de ticket X.

Pour moi, même en php, sans framework, on peut faire ça. Ca ne me parait pas discriminant.

Ce qui est fait par contre d'une manière qu'on pourrait qualifier de plus "artisanale", c'est quand le serveur doit porcéder à un retraitement des données en dehors des interaction des utilisateurs. Dans le monde PHP, on utilisera plutôt un script en crontab. Ca a des inconvenients, mais aussi des avantages (légéreté et modularité par exemple, resistance aux pannes,...)

C'est ça que j'aimerai être certain de pouvoir faire. Une application avec une sorte de console de commande web en django ou autre, ainsi que quelques autres URL maisons qui serviraient de points d'entrée à un webservice travaillant lui aussi sur les données de mon application.

Il n'y a pas d'obstacle majeur, hormis le point que je soulève avant. Si vraiment il faut insérer du code au niveau même du serveur web, j'ai déjà vu une application de ce genre développée en utilisant twisted. Mais je ne peux pas en dire plus, je la connais, mais je n'ai rien fait dessus.

[_skip]

Pour moi, même en php, sans framework, on peut faire ça. Ca ne me parait pas discriminant.

Ce qui est fait par contre d'une manière qu'on pourrait qualifier de plus "artisanale", c'est quand le serveur doit porcéder à un retraitement des données en dehors des interaction des utilisateurs. Dans le monde PHP, on utilisera plutôt un script en crontab. Ca a des inconvenients, mais aussi des avantages (légéreté et modularité par exemple, resistance aux pannes,...)

Oui j'ai vu ça sur des plate-formes ecommerce pour générer des exportations. Ca marchait bien parce que les opérations étaient planifiés (déterministes). Il avait toutefois fallu feinter un peu avec les timeouts du serveur.
Mais c'est vraiment pas une solution qui s'applique pour ce que je souhaite faire.

Il n'y a pas d'obstacle majeur, hormis le point que je soulève avant. Si vraiment il faut insérer du code au niveau même du serveur web, j'ai déjà vu une application de ce genre développée en utilisant twisted. Mais je ne peux pas en dire plus, je la connais, mais je n'ai rien fait dessus.

Après avoir cherché un peu, j'ai l'impression qu'il est assez facile d'embarquer un serveur HTTP dans une application desktop standard. Ca peut me suffire, je vais essayer de faire une proof of concept.
J'oserai pas faire ce genre de serveur maison si c'était un gros truc avec 500 accès concurrents par seconde, mais là je vais tenter de bricoler un truc à titre d'exemple on verra bien.

[wiztricks]

A titre d'exemple : Imaginez simplement une application dans laquelle une interface web est disponible pour lancer des commandes qui mettent 5 min à s'exécuter.
Vous lancez la requête http correspondant à l'action, la fonction côté serveur insère une tâche dans la file et vous retourne un gentil message "votre tâche est en cours de traitement".

Cela n'est pas directement en rapport avec stateless/statefull.
Les requêtes HTTP étant stateless pas nature, 'statefull' signifie associer un contexte à une suite de requêtes HTTP émises par exemple par un même utilisateur.
La possibilité pour un utilisateur de lancer un traitement 'batch' via des requête HTTP "sort" un peu de ce cadre: en fait, nous ne regardons plus ce qu'il se passe entre l'utilisateur et le serveur Web mais "derrière" le serveur Web.

Pour le coup, je dirais qu'on fait ce qu'on veut: on peut passer par cron, des threads, des forks, ... le serveur HTTP n'est qu'une interface utilisateur que l'on propose à cette machinerie - qui du coup peut être réalisée indépendamment du serveur HTTP qui fait "passe plat".

Votre cycle http est fini, pourtant le serveur est bien vivant et bosse, il vous envoie un mail 5 min plus tard pour dire qu'il a fini son boulot et que vous pouvez accéder au résultat d'une URL ou d'un no de ticket X.

Dans ce cas, la partie client/serveur HTTP peut être "stateless": l'application de soumission/lancement/... des traitements devra avoir un minimum de persistance (via fichier, ou BDD) si on veut que les requêtes ne disparaissent pas suite à un reboot ou un crash.

Le serveur HTTP pourrait dans ce cas n'être qu'une interface vers une BDD: création d'un traitement, état d'avancement, retour des résultats,...
Les frameworks Web Django,... permettent de réaliser cela assez "simplement".

L'application qui exécute les traitements pouvant se contenter de récupérer les nouveaux traitements à faire et les exécuter suivant un ordonnancement ad hoc. Le module multiprocessing pourrait servir de base à cela.
- W