Un script php, ou perl, ou shell, ou peu importe le langage, reste du CGI, tant qu'il utilise la RFC en question.
L'intérêt du CGI, c'est de ne pas avoir à développer un module complet dès que tu veux étendre ton serveur http, ou carrément écrire un serveur dédié. C'est aussi un moyen simple de créer un programme qui peut être exécuté sur n'importe quelle machine ayant un serveur http supportant les CGI, qui sont un standard.
Il y a pléthore de langages très bien adaptés à du web interactif ....
Je pourrais apprendre à utiliser un nouveau langage, tel que perl ou python, c'est vrai. Ou supporter l'absence de typage de php. Mais j'ai un impératif de temps aussi.
Et qui à parlé de web interactif?
Le programme en question est un webservice: tu lui poses une question, il te réponds. Pas d'état stocké sur serveur ( je n'ose pas parler de REST, car je n'ai pas fini de lire assez de choses à ce sujet, et je risquerais de déraper, mais disons que je tente de m'inspirer de ce que j'en comprend. )
Donc, la seule chose dont j'ai besoin, c'est de manipuler des chaînes de caractères aisément, chose que le langage que j'ai utilisé fait très bien. Ah, et interroger une DB. Ca aussi, pas de souci.
Comment peux-tu en être certain, vu que le programme qui l'appelle est multithreadé ?
Je voulais juste dire par la que le CGI en question n'utilise pas explicitement de thread multiples.
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 3.
Un script php, ou perl, ou shell, ou peu importe le langage, reste du CGI, tant qu'il utilise la RFC en question.
L'intérêt du CGI, c'est de ne pas avoir à développer un module complet dès que tu veux étendre ton serveur http, ou carrément écrire un serveur dédié. C'est aussi un moyen simple de créer un programme qui peut être exécuté sur n'importe quelle machine ayant un serveur http supportant les CGI, qui sont un standard.
Je pourrais apprendre à utiliser un nouveau langage, tel que perl ou python, c'est vrai. Ou supporter l'absence de typage de php. Mais j'ai un impératif de temps aussi.
Et qui à parlé de web interactif?
Le programme en question est un webservice: tu lui poses une question, il te réponds. Pas d'état stocké sur serveur ( je n'ose pas parler de REST, car je n'ai pas fini de lire assez de choses à ce sujet, et je risquerais de déraper, mais disons que je tente de m'inspirer de ce que j'en comprend. )
Donc, la seule chose dont j'ai besoin, c'est de manipuler des chaînes de caractères aisément, chose que le langage que j'ai utilisé fait très bien. Ah, et interroger une DB. Ca aussi, pas de souci.
Je voulais juste dire par la que le CGI en question n'utilise pas explicitement de thread multiples.