Reprise du message précédent :

Ca ne change pas le problème de se retrouver avec tous les sockets ouverts et de refuser des connections hein, que tu fasses quelque chose avec un socket ou pas, quand il est ouvert il est ouvert

C'est basé sur Red Hat, c'est pas orienté Fancy Pimp Bitched Out Nerdz, c'est assez simple, l'appli Yum est pas mal du tout pour la gestion des paquets.
 
C'est déja plus orienté pro que Ubuntu

 
Bah ouais mais un socket ouvert sur lequel tu n'écoute pas et pour lequel tu n'a pas alloué de thread, ça bouffe un peu de ram et c'est quasiment tout, l'effondrement que tu vois dans ton truc sur Apache tu ne l'aura pas. (Pourquoi tu veut refuser des connections dans ces conditions, ce sont des connections ouvertes hein, spa tout stocké dans le backlog)

Euuuh merci de noter le ":o" à la fin de ma phrase.

En même temps si c'est vraiment un noob et juste pour un petit truc, ubuntu peut faire l'affaire et c'est quand même super simple à installer/utiliser.
 
 
 

Fedora c'est pas non plus la croix et la bannière hein
Limite mettre les mains dans le cambouis ça fait toujours du bien!

Encore un peu et on se croirait sur OSA

Heu, si ca concerne l'installation de serveur web & co, on s'en fout de la facilité de la distrib c'est pas pour la toucher tout les jours, c'est vraiment le genre de truc qui pose aucun problème, tu suis le tuto le plus récent que tu trouve et c'est reglé, le reste c'est la config interne au serveur web et la distrib importe peu.

Masklinn, pour mon histoire de "parse" c'est moi qui est aveugle à la solution ou ça se tient ?

+1
on peut securiser une mandrake ou fragiliser une debian  
 
l'idée c'est de n'installer que le mininimum de truc, bien paramétrer le serveur web , ainsi que les remontée d'erreur
 
et ensuite, le serveur , on y touche plus

C'est pas toi qui les refuse, c'est apache qui se retrouve starved et n'arrive plus à ouvrir de socket de communication, donc il refuse la com' (contrairement aux skyblogs, Apache est limité en coms)

 
Ne pars pas sur Apache Apache est limité en backlog si vraiment il rame, mais ça n'arrive que si le serveur n'a même pas le temps d'ouvrir les connections, ce qui n'est pas le cas du truc que j'explique. Ensuite il est limité par le nombre de thread et leur temps de création, mais ça nous touche pas non plus vu qu'on crée pas de thread pour des connections ouvertes mais non utilisées pour le moment.
 
(En fait faudrait plutôt raprocher ça d'une connection sur un serveur IRC en quelque sort, sans la coopération du gentil navigateur. Apache n'est pas optimisé pour cette facon de l'utiliser, mais créer un client spécifique ne couterait pas grand chose (En Erlang par exemple ) )

Strobien le Zend Framework
 
(c'est tout)

Ouais enfin il te faut quand même un serveur HTTP derrière parce que xmlHttpRequest aux dernières nouvelles tu peux pas l'utiliser pour faire des requêtes TCP raw

 
   
 
-----------------------------
Sinon pour ma question de ce qui est mieux pour communiquer aux clients les changements des autres.
Le choix sera sans doute, d'utiliser un protocole XMPP, un peu modifié
 
Voilà voilà

J'utilise ni Dojo ni les JSF donc j'en ai strictement aucune idée

 
Lol    
 
Pas de soucis, faut pas que le grand Masklinn ai des limites dans ses connaissances, sinon on va vraiment croire que tu es un extraterrestre.

Rho... quand t'as pas envie t'es un peu mou du genou

Ça reste un serveur HTTP, mais tuné différement et qui ne s'occupe que de ce genre de requète xHR, il recoit la requète du client normalement et la seule différence c'est au moment de répondre, il n'envoie pas tout d'un coup, mais seulement ce qu'il veut quand il veut, évidemment si le navigateur en face est synchrone, l'utilisateur va faire la gueule

c'est facile à realiser si il s'agot juste de faire un ping  
 
mais tu dois aussi faire une action cote serveur pour verifier si il y a une modif a envoyer  
 
de plus , les requetes xmlhttprequest doivent se faire sur le même serveur ( ip et port ) , donc pas facile de faire cohabiter deux serveurs( a moins qu'il y ait un moyen de depasser cette limite autre que de coder un proxy )

Putain de bourdel, j'écris transparent ou quoi?

je sais pas, j'ai loupé quoi ?    
(cet apres midi j'ai pas mal avancé, corollaire ; j'ai pas trop suivi le forum )  
 
ps : yahoo.ui , c'est que du bonheur , j'ai fait un simili explorateur windows en une demi journée  

Le truc c'est d'utiliser les header ( genre 304 )

 
On a le droit d'explorer d'autres idées

+1
mais meme avec des header , ca fait quand meme une connection au serveur, et c'est de la qu'est parti le debat il me semble ( faire un serveur qui soit optimiser pour ce type de requetes )  
 

Ce header teste si la page à été modifiée, et ça va pas plus loin, je vois pas grand chose de plus léger
(C'est ce qu'utilise entre autre smart pour son système de cache)

 
La soluce que je propose permet d'être 10x plus réactif et de consommer 10x moins de bp (mais un peu plus de ram sur le serveur et plus d'effort initial de prog que du js/php ).
 
( Je crois que jvais devoir faire une démo pour convaincre )

Non, le débat est parti de mon problème avec les connections "permanentes" (qui sont ce que 0x90 conseille)

 
Je conseille pas, je propose, j'ai jamais fait de tests réels la dessus

Je me pose une question, en html y-a-t'il un quelconque attribut autorisé dans les balises de fermeture, pour les identifier.

Pour le moment j'utilise les commentaires :

Mais je me demandais s'il était possible de mettre quelque chose directement dans la balise.

 
J'vois pas l'intérêt de faire ça, le parsing d'un document complet et bien formé (avec toutes les balises fermées) n'a rien de difficile
 
Surtout si tu ne le fais pas toi même

Pour plusieurs raison.
 
Déjà j'ai mes fichiers header et footer séparés, donc j'aime bien repéré rapidement qui ferme quoi parmi mes echainement de </div> par exemple.
 
Ensuite, même pour un fichier de contenu, et même bien indenté, une fois qu'il est bien rempli, je trouve intéressant de savoir quelle balise ferme quoi.
 
Je ne parle pas de mettre ça pour toutes les balises non plus hein Mais juste pour mes gros blocs conteneurs, et uniquement pour des raisons pratiques.

Avec une bonne indentation et des commentaires juste après tes balises de fermeture ça devrait largement suffir  

Oui mais non, il a raison, si tu as une tête de page sur 400 lignes, entre le début et la fin, tu perds visuellement t'es répère, un simple /* Fin de la tête de page */ est clairement plus simple pour s'y retrouver.

 
 
 
C'est comme ça que je fais non ?
 
Mais comme ça oblige à rajouter des commentaires, je me suis dis qu'il y avait peut être une possibilité quelconque d'ajouter un identifiant à l'intérieur de la balise fermante.
 
Mais si ce n'est pas possible je continue avec mes commentaires, c'est pas grave, c'était juste "au cas où"

Chtite question : comment on fait en js pour identifier quel submit a été cliqué ?  
 

Bah tu mets un onclick sur le button plutot qu'un onsubmit.

Ben ouais.... Chais pas pourquoi je cherchais une solution qu'avec le onsubbmit
 

Dites, l'un d'entre vous aurait connaissance d'un exemple de script de comptage d'upload ?
Vous savez genre quelqu'un uploade une image d'un mega et ça affiche 5%, 10%, une espèce d'ascenseur quoi.
Ou si vous êtes calé, vous pouvez aussi me mettre sur la voie, j'ai rien contre.
 
J'imagine le truc, l'user clique sur le bouton "Upload", ça submit le form et en même temps, ça ouvre une petite fenêtre qui regarde où en est la taille du fichier, petite fenêtre qui se rafraichi toutes les demis secondes par exemple.
Le problème, c'est comment avoir la taille finale du fichier qui doit être uploader avant qu'il ne le soit et la taille/le nom du fichier temporaire.
 
Si vous avez des indices à me filer, ça serait sympa.

Ha quand on demande des trucs faciles, y'a du monde, mais là, un truc un peu plus pointu, y'a plus personne.
Evidement, tout le monde va me dire qu'ils ont une vie et autre chose à faire le samedi après midi ensoleillé.

Je suis pas sur que tu puisse y arriver en PHP.
Tu peut avoir la taille totale elle est dans le header HTTP, je sais pas si PHP la fait passer. Ensuite il te faut monitorer son transfert donc pouvoir être informé dès le début de celui ci, et stocker ça dans une petite base temporaire.

dans tous les cas que j'ai pu voir ca demande une configuration spécifique coté serveur

http://encodable.com/filechucker/ devrait faire ton bonheur

edit , c'est payant au fait , mais il existe des scripts gratuits

et  a priori , on peut pas le faire ne php , masi en perl c'est possible
en php , on ne peux pas savori on en est l'upload

Tu peux, logiquement tu peux récuperer l'id de la form via l'élement enfant qui provoque son envoi.