__o a écrit 218 commentaires

Ça a l'air pas mal du tout, mais comment ça se passe lorsqu'on veut persister les données sur un serveur ? Est-ce qu'on ne risque pas d'avoir à implémenter deux fois le modèle ? (sur le serveur et le client)

Ça revient un peu au même que ce qui est fait avec les certificats auto-signés :) la première fois tu refuses ou tu ajoutes une exception et c'est tout.

Il y a une API asynchrone pour les accès disques aussi ?

On se retrouve pas avec 40 méthodes "callbacks" éparpillées un peu partout dans le code, quand on fait de l'asynchrone sans closures ?

Et donc pour gziper un gros fichier, tu patch zlib pour ajouter des qApp->processEvents() dedans ?

Pour faire une requête HTTP tu fais une résolution DNS asynchrone + une connexion TCP asynchrone + des I/0 asynchrones etc ? Et donc tu garde un état de tout ça quelque part. Tu as un code qui commence à devenir très compliqué. C'est certainement plus simple de faire un thread, voir un process, qui ne touche qu'à ses données locales et communique avec le thread de la gui par messages.

Oui, c'est comme ça qu'on fait des GUI qui freezent non ? :-) (Je suppose que si le code ne rend pas la main à la gui pendant plusieurs secondes, c'est autant de secondes pendant lesquelles la gui est freezée.) Du coup c'est peut être mieux de faire certaines choses dans un thread séparé de celui de la gui.

si le firewall ne bloque pas

Oui donc ça n'empêche pas l'opérateur de l'autoriser, si il le voulait

c'est ton mobile qui initie la connexion

Sauf que l'IP est un protocole hors connexion. Tu inities une connexion TCP. Pas une connexion IP. Tu envois juste un paquet vers un destinataire.

Et donc si linuxfr peut t'envoyer des paquets IP contenant des paquets TCP contenant un bout de page web, linuxfr pourrait très bien t'envoyer un paquet IP contenant un paquet TCP SYN pour initialiser une connexion entrante avec ton mobile. Il suffirait que ton mobile ait une IP publique routée par ton opérateur.

Dans une connexion entre ton mobile et linuxfr, il y a des paquets IP qui passent dans les deux sens. Ça veut dire qu'un mobile peut recevoir des paquets IP. Et donc il peut recevoir une connexion entrante. Il faut juste que l'opérateur te donne une IP publique et la route.

ok en effet ici c'était pas une mauvaise idée :)

C'est inutile d'échapper tout le temps la donnée si elle peut l'être qu'une seule fois au moment de la sauvegarde

Heu dans ce cas précis ok, mais la phrase est tournée comme si ça s'appliquait en général ;-)

Dans le cas général c'est juste une fausse bonne idée, on se retrouve à jongler avec des données dont on ne sait plus trop lesquelles sont échappées ou pas, pour quoi elles sont échappées, etc. En plus un fonction d'échappement html c'est un remplacement de 4 caractères dans une chaîne, c'est pas une fonction coûteuse.

Sans oublier les quotes :)

Les données sont enregistrées échappées ? Pourquoi ne pas le faire à l'affichage ? C'est pas la vue qui devrait se charger de ce genre de choses ? (et le moteur de template le fait pas automatiquement ?)

Il n'a pas parlé de regarder le code ;-)

Peut être parce que par défaut, il utilise un moteur non-transactionnel

Pour cause de compatibilité.

Mais dans la dernière version le moteur par défaut est transactionnel / ACID / avec clés étrangères / etc ;-)

Pour l'administration je sais pas; qu'est-ce que PgSQL offre de génial que ne fait pas MySQL à ce niveau ?

GNU grep est moins propre que <posix-compliant grep> parce que en plus des options standards il a aussi des options pas standards ?

Personne n'est obligé d'utiliser les extensions de syntax de MySQL hein :)

ha non c'est revenu :(

On dirait que ça a été changé, merci ! :-)

Et par contre Gnome ça les dérange pas d'avoir un contrat d'affiliation avec Amazon ?

Si en plus Amazon était un vendeur DRMs et d'eBooks au format propriétaire, les revenus d'affiliation des développeurs de Banshee seraient presque un problème secondaire.

Mais j'ai pas dis que nginx est mal ou mauvais.

D'ailleurs je ne nie pas qu'il puisse offrir de meilleurs performances sur un serveur de fichiers statiques avec un peu plus de 1K requêtes par secondes, si les disques jouent pas les goulots d'étranglement avant.

Par contre dans 99% des cas on vois pas la différence, même pour des serveurs de fichiers statiques (parce que pour occuper 100% du CPU avec un serveur HTTP, il faut y aller quand même).

Et donc j'ai juste dis que dans le nombre d'instances nginx qui tournent actuellement, dans 99% des cas le choix ne s'est pas fait sur « mon propre benchmark montre que je tiens mieux la charge avec nginx sur ma propre application » ou sur « nginx a une killer feature dont j'ai besoin », mais plutôt sur « on m'a dit que nginx c'est bon mangez en ».

Alors effectivement sur le nombre d'instances, si nginx était mauvais ça se verrais, mais j'ai jamais dis que nginx était mauvais.

Par contre oui je doute que dans 99% des cas ça ait un impact visible sur les performances de l'app.

Et donc oui c'est le serveur à la mode.

Et alors ?

Merci.

Je cherchais juste à montrer que nginx n'était pas utilisé pour ces qualité, mais parce que c'est le serveur "à la mode", ou "conseillé dans tel article", ou "parce que je sais l'installer", et puis comme ça marche, on le garde. Et donc que le nombre d'instances de nginx ne veut rien dire du tout du point de vu des performances ou quoi que ce soit.

Et tu pense que ces millions de serveurs ont tous été installés après avoir effectué des tests comparatifs poussés ?

nginx est devenu plus ou moins le serveur par défaut dans la tête des gens, tout comme apache l'était il y a quelques temps.

Actuellement quand on installe un nginx c'est pas pour des raisons techniques ou pratiques; après avoir effectué des tests comparatifs poussés entre plusieurs serveurs.

C'est juste parce que c'est le serveur à la mode actuellement, ou parce que le tutoriel d'installation de django-on-rails disait d'installer nginx, ou juste parce que vous avez vu un article qui disait que c'est vachement bien.

Un autre avantage est que nginx commence beaucoup moins de mémoire qu'apache (du genre 5x à 10x moins).

Par rapport à un apache qui a 10 modules chargés, dont mod(ruby|php|python) ? Ou par rapport à un apache utilisé de la même façon que nginx ? Sinon il y a de fortes chances pour que le mod(ruby|php|python) soit responsable d'une bonne partie de la mémoire utilisée.

Noelshack

mouton-shack

Heu nginx c'est pas juste une mode ? J'ai du mal à imaginer qu'un serveur http puisse être le goulot d'étranglement d'une app web. Même en faisant un benchmark, je suis pas sûr que la différente soit visible sur des pages dynamiques.

Par exemple ?

À part ce détail; [✓] Génial, et bravo :-)

La font utilisée partout sur le site me semble un peu "floue", comme si l'hinting n'était pas activé dessus. Du coup ça fait mal aux yeux, en vrai.