Pierre Quentel a écrit :
> Bonjour,
>
>> J'ai testé également Karrigell qui est très proche de l'esprit python
>> mais qui se destine à des développements plus modestes selon
>> l'auteur...
>
> L'auteur de Karrigell (moi-même) a été trop prudent dans les premières
> annonces
> il y a 5 ans et ça continue de lui coller à la peau... Maintenant
> qu'il est bien intégré à Apache, je ne vois pas ce qu'on peut faire
> avec Django qu'on ne pourrait pas faire avec Karrigell ; avec
> l'avantage d'une plus grande simplicité d'accès
>
> A+
> Pierre Quentel
>
J'utilise Karrigell pour mon site perso ainsi que pour le site d'un cinéma de province.
Je n'ai pas de problèmes de perf (peu de visiteurs).
J'utilise le serveur intégré à Karrigell (pas derrière apache) sur un PC sous Win XP.
C'est très accessible (même pour un novice comme moi), bien documenté, avec des fonctionnalités très intéressantes comme les HTML tags, les virtual hosts...
L'auteur (Pierre Quentel) est très réactif sur les corrections de bugs et améliorations.
Bref, que du bonheur.

J'avais un site programmé en php+MySQL sur un serveur pages perso Free. Free (ou les robots de celui-ci) a décidé de fermer ce site de façon sauvage (même pas prévenu). Je l'ai donc changé de serveur et j'en ai profité pour le réécrire en python avec Karrigell. Au ch... php ! Vive Python et karrigell. Ca m'a même donné envie de refaire du développement dessus pour l'améliorer un peu.

Nicolas

Pierre Quentel a écrit :
> Bonjour,
>
>> J'ai testé également Karrigell qui est très proche de l'esprit python
>> mais qui se destine à des développements plus modestes selon
>> l'auteur...
>
> L'auteur de Karrigell (moi-même) a été trop prudent dans les premières
> annonces
> il y a 5 ans et ça continue de lui coller à la peau... Maintenant
> qu'il est bien intégré à Apache, je ne vois pas ce qu'on peut faire
> avec Django qu'on ne pourrait pas faire avec Karrigell ; avec
> l'avantage d'une plus grande simplicité d'accès
>
> A+
> Pierre Quentel
>
J'utilise Karrigell pour mon site perso ainsi que pour le site d'un cinéma de province.
Je n'ai pas de problèmes de perf (peu de visiteurs).
J'utilise le serveur intégré à Karrigell (pas derrière apache) sur un PC sous Win XP.
C'est très accessible (même pour un novice comme moi), bien documenté, avec des fonctionnalités très intéressantes comme les HTML tags, les virtual hosts...
L'auteur (Pierre Quentel) est très réactif sur les corrections de bugs et améliorations.
Bref, que du bonheur.

J'avais un site programmé en php+MySQL sur un serveur pages perso Free. Free (ou les robots de celui-ci) a décidé de fermer ce site de façon sauvage (même pas prévenu). Je l'ai donc changé de serveur et j'en ai profité pour le réécrire en python avec Karrigell. Au ch... php ! Vive Python et karrigell. Ca m'a même donné envie de refaire du développement dessus pour l'améliorer un peu.

Nicolas

On 09-10-2007, Pierre Quentel wrote:
> Bonjour,
>
>> J'ai testé également Karrigell qui est très proche de l'esprit python
>> mais qui se destine à des développements plus modestes selon
>> l'auteur...
>
> L'auteur de Karrigell (moi-même) a été trop prudent dans les premières
> annonces
> il y a 5 ans et ça continue de lui coller à la peau... Maintenant
> qu'il est bien intégré à Apache, je ne vois pas ce qu'on peut faire
> avec Django qu'on ne pourrait pas faire avec Karrigell ; avec
> l'avantage d'une plus grande simplicité d'accès

Qu'est-ce que tu veux dire par 'bien intégré à apache' ?

--
William Dodé - http://flibuste.net
Informaticien indépendant

On 09-10-2007, Pierre Quentel wrote:
> Bonjour,
>
>> J'ai testé également Karrigell qui est très proche de l'esprit python
>> mais qui se destine à des développements plus modestes selon
>> l'auteur...
>
> L'auteur de Karrigell (moi-même) a été trop prudent dans les premières
> annonces
> il y a 5 ans et ça continue de lui coller à la peau... Maintenant
> qu'il est bien intégré à Apache, je ne vois pas ce qu'on peut faire
> avec Django qu'on ne pourrait pas faire avec Karrigell ; avec
> l'avantage d'une plus grande simplicité d'accès

Qu'est-ce que tu veux dire par 'bien intégré à apache' ?

--
William Dodé - http://flibuste.net
Informaticien indépendant

On 9 oct, 12:18, William Dode <w...@flibuste.net> wrote:

>
> Qu'est-ce que tu veux dire par 'bien intégré à apache' ?
>
Bonsoir,

Il y a deux façons de faire tourner Karrigell derrière Apache :

- lancer le serveur intégré et rediriger toutes les requêtes qui
arrivent sur le serveur Apache vers ce serveur intégré. On conserve
tous les avantages de ce serveur, notamment le fait qu'on reste
toujours sur le même processus pour l'interpréteur Python, donc pas
d'overhead CGI et possibilité de gérer les sessions en mémoire. Par
contre il faut avoir le droit de lancer un processus long sur le
serveur, ce qui est plutôt rare en hébergement partagé (webfaction.com
le permet)

- plus récemment j'ai développé un module qui permet de faire tourner
les scripts Karrigell avec simplement mod_rewrite et mod_cgi, sans
processus long à faire tourner. On reste dans une interface CGI donc
avec l'overhead correspondant, mais à l'usage pour le site que j'ai
développé sur un Intranet ça se voit à peine. Et ça augmente nettement
le nombre d'hébergeurs potentiels, il suffit de configurer un hôte
virtuel dans httpd.conf

Pas de fonctionnement possible en mode multithread, notamment parce
que le répertoire courant est changé à chaque requête pour permettre
les références relatives ; donc l'intégration avec mod_python ne
fonctionne pas, ou alors en trichant (un lock() au début de la requête
et un release() à la fin...)

Les deux premières options sont décrites en détail dans la doc ; il y
a bien sûr une version française...

A+
Pierre

On 9 oct, 12:18, William Dode <w...@flibuste.net> wrote:

>
> Qu'est-ce que tu veux dire par 'bien intégré à apache' ?
>
Bonsoir,

Il y a deux façons de faire tourner Karrigell derrière Apache :

- lancer le serveur intégré et rediriger toutes les requêtes qui
arrivent sur le serveur Apache vers ce serveur intégré. On conserve
tous les avantages de ce serveur, notamment le fait qu'on reste
toujours sur le même processus pour l'interpréteur Python, donc pas
d'overhead CGI et possibilité de gérer les sessions en mémoire. Par
contre il faut avoir le droit de lancer un processus long sur le
serveur, ce qui est plutôt rare en hébergement partagé (webfaction.com
le permet)

- plus récemment j'ai développé un module qui permet de faire tourner
les scripts Karrigell avec simplement mod_rewrite et mod_cgi, sans
processus long à faire tourner. On reste dans une interface CGI donc
avec l'overhead correspondant, mais à l'usage pour le site que j'ai
développé sur un Intranet ça se voit à peine. Et ça augmente nettement
le nombre d'hébergeurs potentiels, il suffit de configurer un hôte
virtuel dans httpd.conf

Pas de fonctionnement possible en mode multithread, notamment parce
que le répertoire courant est changé à chaque requête pour permettre
les références relatives ; donc l'intégration avec mod_python ne
fonctionne pas, ou alors en trichant (un lock() au début de la requête
et un release() à la fin...)

Les deux premières options sont décrites en détail dans la doc ; il y
a bien sûr une version française...

A+
Pierre

On 09-10-2007, Pierre Quentel wrote:

> Pas de fonctionnement possible en mode multithread, notamment parce
> que le répertoire courant est changé à chaque requête pour permettre
> les références relatives ;

Je ne comprend pas ce que tu veux dire... C'est en mode cgi que le mode
multithread n'est pas possible ? Mais je ne vois pas l'intérêt du
multithread en cgi.

bye

--
William Dodé - http://flibuste.net
Informaticien indépendant

On 09-10-2007, Pierre Quentel wrote:

> Pas de fonctionnement possible en mode multithread, notamment parce
> que le répertoire courant est changé à chaque requête pour permettre
> les références relatives ;

Je ne comprend pas ce que tu veux dire... C'est en mode cgi que le mode
multithread n'est pas possible ? Mais je ne vois pas l'intérêt du
multithread en cgi.

bye

--
William Dodé - http://flibuste.net
Informaticien indépendant

On 9 oct, 21:42, William Dode <w...@flibuste.net> wrote:
>
> Je ne comprend pas ce que tu veux dire... C'est en mode cgi que le mode
> multithread n'est pas possible ? Mais je ne vois pas l'intérêt du
> multithread en cgi.

Non, je voulais dire que Karrigell ne peut pas fonctionner avec
mod_python notamment, à cause du multithread

Pierre

On 9 oct, 21:42, William Dode <w...@flibuste.net> wrote:
>
> Je ne comprend pas ce que tu veux dire... C'est en mode cgi que le mode
> multithread n'est pas possible ? Mais je ne vois pas l'intérêt du
> multithread en cgi.

Non, je voulais dire que Karrigell ne peut pas fonctionner avec
mod_python notamment, à cause du multithread

Pierre

On 10-10-2007, Pierre Quentel wrote:
> On 9 oct, 21:42, William Dode <w...@flibuste.net> wrote:
>>
>> Je ne comprend pas ce que tu veux dire... C'est en mode cgi que le mode
>> multithread n'est pas possible ? Mais je ne vois pas l'intérêt du
>> multithread en cgi.
>
> Non, je voulais dire que Karrigell ne peut pas fonctionner avec
> mod_python notamment, à cause du multithread

Si le mode standalone de karrigell ne peut pas fonctioner en multithread
ça limite quand même pas mal les sites très fréquentés ou avec des
requetes bloquantes non ?


--
William Dodé - http://flibuste.net
Informaticien indépendant

On 10-10-2007, Pierre Quentel wrote:
> On 9 oct, 21:42, William Dode <w...@flibuste.net> wrote:
>>
>> Je ne comprend pas ce que tu veux dire... C'est en mode cgi que le mode
>> multithread n'est pas possible ? Mais je ne vois pas l'intérêt du
>> multithread en cgi.
>
> Non, je voulais dire que Karrigell ne peut pas fonctionner avec
> mod_python notamment, à cause du multithread

Si le mode standalone de karrigell ne peut pas fonctioner en multithread
ça limite quand même pas mal les sites très fréquentés ou avec des
requetes bloquantes non ?


--
William Dodé - http://flibuste.net
Informaticien indépendant

On 10 oct, 11:43, William Dode <w...@flibuste.net> wrote:

> Si le mode standalone de karrigell ne peut pas fonctioner en multithread
> ça limite quand même pas mal les sites très fréquentés ou avec des
> requetes bloquantes non ?
>

Ca dépend ce qu'on appelle très fréquentés... On ne fera pas tourner
Google sur Karrigell, c'est sûr ! Mais le serveur intégré qui tourne
en autonome ou derrière Apache est un serveur asynchrone, basé sur les
modules asyncore et asynchat, avec les performances très élevées qui
vont avec, au moins aussi bonnes que le multithread (le changement
d'un thread à un autre consomme du temps et de la ressource)

Bien sûr s'il y a des requêtes bloquantes le multithread est la seule
solution efficace

Au total je suis convaincu que Karrigell convient dans au moins 95%
des cas en termes de performances (on ne dispose hélas pas de chiffres
sur la fréquentation moyenne des sites web). Pour couvrir 100% des cas
il faudrait alourdir nettement le style de programmation, et à choisir
je préfère que l'apprentissage et la mise en oeuvre restent simples

Je pense rester dans l'esprit du langage Python, qui ne prétend pas
non plus couvrir 100% des cas de figure (justement dans les cas que tu
cites, où la vitesse d'exécution est cruciale) mais qui ne fait pas de
compromis sur la lisibilité du code et la facilité de développement

Pierre

On 10 oct, 11:43, William Dode <w...@flibuste.net> wrote:

> Si le mode standalone de karrigell ne peut pas fonctioner en multithread
> ça limite quand même pas mal les sites très fréquentés ou avec des
> requetes bloquantes non ?
>

Ca dépend ce qu'on appelle très fréquentés... On ne fera pas tourner
Google sur Karrigell, c'est sûr ! Mais le serveur intégré qui tourne
en autonome ou derrière Apache est un serveur asynchrone, basé sur les
modules asyncore et asynchat, avec les performances très élevées qui
vont avec, au moins aussi bonnes que le multithread (le changement
d'un thread à un autre consomme du temps et de la ressource)

Bien sûr s'il y a des requêtes bloquantes le multithread est la seule
solution efficace

Au total je suis convaincu que Karrigell convient dans au moins 95%
des cas en termes de performances (on ne dispose hélas pas de chiffres
sur la fréquentation moyenne des sites web). Pour couvrir 100% des cas
il faudrait alourdir nettement le style de programmation, et à choisir
je préfère que l'apprentissage et la mise en oeuvre restent simples

Je pense rester dans l'esprit du langage Python, qui ne prétend pas
non plus couvrir 100% des cas de figure (justement dans les cas que tu
cites, où la vitesse d'exécution est cruciale) mais qui ne fait pas de
compromis sur la lisibilité du code et la facilité de développement

Pierre

On 10-10-2007, Pierre Quentel wrote:

> Au total je suis convaincu que Karrigell convient dans au moins 95%
> des cas en termes de performances (on ne dispose hélas pas de chiffres
> sur la fréquentation moyenne des sites web). Pour couvrir 100% des cas
> il faudrait alourdir nettement le style de programmation, et à choisir
> je préfère que l'apprentissage et la mise en oeuvre restent simples

Le tout est de savoir à quoi s'en tenir suivant ses besoins
effectivement.

--
William Dodé - http://flibuste.net
Informaticien indépendant

On 10-10-2007, Pierre Quentel wrote:

> Au total je suis convaincu que Karrigell convient dans au moins 95%
> des cas en termes de performances (on ne dispose hélas pas de chiffres
> sur la fréquentation moyenne des sites web). Pour couvrir 100% des cas
> il faudrait alourdir nettement le style de programmation, et à choisir
> je préfère que l'apprentissage et la mise en oeuvre restent simples

Le tout est de savoir à quoi s'en tenir suivant ses besoins
effectivement.

--
William Dodé - http://flibuste.net
Informaticien indépendant

Bruno Desthuilliers a écrit :
> jean-michel bain-cornu a écrit :
>> Bonjour,
> [SNIP]
>> Quant à Zope3, c'est encore pire. Je n'arrive à le faire fonctionner
>> que sous linux, en suivant pas à pas un tutoriel
>> (http://www.ibiblio.org/obp/pyBiblio/zope3/quickstart/) qui prends 10
>> pages pour afficher 'hello world' (oui, print 'hello world' en cgi...).
>
> Aucun serveur d'application complexe n'est à son avantage sur un exemple
> de ce genre. Ta comparaison est donc peu concluante.
>
> Ceci étant, même s'il y a (certainement) des choses très intéressantes
> dans Zope3, personnellement, j'ai décroché des usines à gaz !-)

Il ne faut pas utiliser Zope3 tel quel. Lennart vient de faire une très
bonne conférence à ce sujet durant la Plone Conf 2007.

Pour éviter de perdre du temps il faut utilser grok qui permet d'être
efficace avec un bonne courbe d'apprentissage.

Traduction Libre : «Si vous avez un problème et que XML est votre
réponse, alors vous n'avez pas compris la question.»

--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

Bruno Desthuilliers a écrit :
> jean-michel bain-cornu a écrit :
>> Bonjour,
> [SNIP]
>> Quant à Zope3, c'est encore pire. Je n'arrive à le faire fonctionner
>> que sous linux, en suivant pas à pas un tutoriel
>> (http://www.ibiblio.org/obp/pyBiblio/zope3/quickstart/) qui prends 10
>> pages pour afficher 'hello world' (oui, print 'hello world' en cgi...).
>
> Aucun serveur d'application complexe n'est à son avantage sur un exemple
> de ce genre. Ta comparaison est donc peu concluante.
>
> Ceci étant, même s'il y a (certainement) des choses très intéressantes
> dans Zope3, personnellement, j'ai décroché des usines à gaz !-)

Il ne faut pas utiliser Zope3 tel quel. Lennart vient de faire une très
bonne conférence à ce sujet durant la Plone Conf 2007.

Pour éviter de perdre du temps il faut utilser grok qui permet d'être
efficace avec un bonne courbe d'apprentissage.

Traduction Libre : «Si vous avez un problème et que XML est votre
réponse, alors vous n'avez pas compris la question.»

--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

Encolpe Degoute a écrit :

> Traduction Libre : «Si vous avez un problème et que XML est votre
> réponse, alors vous n'avez pas compris la question.»

Je n'ai pas vu la conférence, mais pour moi XML s'avere souvent etre un
outil efficace pour la résolution de nombreux problemes

Encolpe Degoute a écrit :

> Traduction Libre : «Si vous avez un problème et que XML est votre
> réponse, alors vous n'avez pas compris la question.»

Je n'ai pas vu la conférence, mais pour moi XML s'avere souvent etre un
outil efficace pour la résolution de nombreux problemes

JB a écrit :
> Encolpe Degoute a écrit :
>
>> Traduction Libre : «Si vous avez un problème et que XML est votre
>> réponse, alors vous n'avez pas compris la question.»
>
> Je n'ai pas vu la conférence, mais pour moi XML s'avere souvent etre un
> outil efficace pour la résolution de nombreux problemes

Ce n'est pas dans la conférence, mais une citation que j'ai retrouvé à
plusieurs endroit.
L'idée par rapport à Zope 3 est que le XML était initialement prévu pour
être un format de transfert entre applications. Dans Zope 3 cela à la
fois de fichier de configuration et d'outil de développement.

--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

JB a écrit :
> Encolpe Degoute a écrit :
>
>> Traduction Libre : «Si vous avez un problème et que XML est votre
>> réponse, alors vous n'avez pas compris la question.»
>
> Je n'ai pas vu la conférence, mais pour moi XML s'avere souvent etre un
> outil efficace pour la résolution de nombreux problemes

Ce n'est pas dans la conférence, mais une citation que j'ai retrouvé à
plusieurs endroit.
L'idée par rapport à Zope 3 est que le XML était initialement prévu pour
être un format de transfert entre applications. Dans Zope 3 cela à la
fois de fichier de configuration et d'outil de développement.

--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales