re
Jérôme Fenal a écrit :
> From: yann [mailto:yann.forgerit@free.fr]
> Sent: Friday, January 10, 2003 12:39 PM
> To: Jérôme Fenal
> Cc: spip-dev@rezo.net
> Subject: Re: [spip-dev] [Patch] Correction de bug d'indexation<mode chasse_au_troll=1>
> Le pb est que :
> - la très grande majorité des hébergeurs font au "plus petit
> dénominateur commun" au niveau des ressources allouées à un site Web,
> - ils calquent, vraisemblablement, de plus en plus leur
> attitude sur le
> fait que si vous faîtes du Php/Mysql => Vous êtes un "pro". Si vous
> n'êtes capable que de faire du html "statique", vous êtes le
> bon client
> pour eux => vous allez pas leur bouffer de la ressource serveur.
> Je viens de lire queque chose "d'édifiant" à ce sujet sur
> http://www.hebergement-discount.com/secret.html??? Quel est le rapport ???
>
> Je me demande dans quelle mesure, si on commence à vouloir se
> baser sur
> la version Php de l'hébergeur, on ne va au devant d'énormes pbs. Les
> limitations au niveau de php sont tellement variées d'un hébergeur à
> l'autre que l'on risque de se retrouver dans la situation où Spip va
> passer plus de temps à essayer ce que l'hébergeur accepte plutôt qu'à
> afficher une page Spip !! Quand on sait que de plus en plus
> d'hébergeurs
> limitent le time_out sur les scripts en php, au bout d'un moment,
> comment on va faire ?? Le "time_out" sera "bouffé" en vérifications
> avant que Spip ai pu, ne serait-ce que commencer à calculer la page ??Certes, et ma pseudo rustine de ce matin est là pour corriger un problème d'affichage, pas de timeout.
(Il est vrai que j'aurai dû changer le sujet du mél, ce que je fais de ce pas.)
(Il est vrai aussi que celui d'hier corrigeait le pb de timeout).> Le truc ci-dessus est très, très bien mais il ne pourra que
> fonctionner
> sur un hébergeur pro, ce qui est très loin de la majorité des
> utilisateurs de Spip (C.F. la liste) ??D'où la nécessité de tester dans la partie admin (un meta de plus, je te l'accorde) si les pcre sont là.
Si ce n'est pas le cas, tant pis.
</mode><mode feed_the_troll=1e38>
Cela dit, libre à Fil de ne pas inclure mes modifications.
Ce serait dommage, et d'abord pour moi, mais j'ai déjà fait avec quand je maintenais mon patch pour l'utilisation d'un proxy. Le fait que le patch soit inclus dans SPIP me simplifie la vie, c'est tout, mais c'est beaucoup pour moi.
Et c'est l'avantage d'un logiciel libre : libre à toi (et aux développeurs) de ne pas inclure les modifications _proposées_ (j'insiste sur le terme de proposition.)
Libre à moi aussi de ne pas diffuser mes modifications si je ne diffuse pas l'application.
</mode>Cdt,
J.
PS : je continuerai à produire ici mes (très) modestes contributions à SPIP. Fin du troll.
Mon propos n'était pas d'introduire un "troll" ou de mettre en doute le
bien fondé de ta contribution 
loin de moi cette idée !!
Je me pose juste la question : "Jusqu'où est-il possible de tester les
possibilités d'un hébergeur avant d'arriver au terme de ce qu'il est
prêt à accepter comme charge de traitement d'un script ??"
Les possibilités d'exécution d'un script devenant de plus en plus
restreintes, je me pose la question de : Jusqu'où peut on aller ??
Par contre, tu m'as donné une super idée (et je t'en remercie) pour un
"client" mais là, le pb est différent car je "maîtrise" l'hébergement
(c'est pas moi qui héberge mais je peux faire ce que je veux (compiler
une autre version de php et mysql, je fais ce que je veux tant au niveau
d'apache, que de php ou mysql, voire même des libs que je veux ou pas),
car c'est un hébergement professionnel sur serveur dédié.
Après, que ce soit intégré ou pas dans Spip, cela reste de la décision
des développeurs de Spip et pas, juste parce qu'ils en ont envie, de
ceux qu'ils l'utilisent. Cela n'a rien contre toi, c'est juste un pb
"technique" au niveau de l'hébergement pour répondre aux besoins de
l'utilisateur "moyen" de Spip
A+ Yann