Un protocole conçu pour ça, précisément, pas Hyper Text Transport "Quand j'ai un marteau tout ressemble à un clou" Protocol ;). Bon je reconnais que j'exagère, il y a surement lieu de s'inspirer du mail pour améliorer le web (y compris, peut-être, l'IDLE d'IMAP). Mais la situation est différente et beaucoup plus facile à gérer pour le mail :
o C'est éminemment, naturellement shardable / partitionable (à la différence d'une application appuyée sur une base de donnée relationnelle, les mailboxes sont des "data stores" très faciles à dispatcher et répartir). A l'opposé des prérequis pour la construction, par exemple, d'un graphe de réseau social. Voir à ce sujet les réflexions de James Hamilton, par exemple ici : http://perspectives.mvdirona.com/2008/06/08/ScalingLinkedIn.(...)
Ok, rien à voir avec le sujet de ce thread, mais en écho au thème des nouveaux systèmes de stockage NoSQL.
o Des questions de volumes et de dimensionnements (prévisibles ou pas). Le trafic (nombre de connexions) d'un serveur IMAP est généralement facile à anticiper, ou du moins suit des évolutions prédictibles; un trafic normalement limitée à l'ensemble des utilisateurs connus et enregistrés. Servis par un applicatif minimal et quasi non bloquant (hormis l'auth, presque de pures I/O). L'applicatif est en même temps directement le serveur de stockage. Naturellement asynchrone. Je ne crois pas qu'il y ai beaucoup d'environnement IMAP dans le monde qui ont l'occasion de recevoir 100 000 connexions simultanées, ni même 10k. Ca n'est pas tout à fait de même nature que les vagues de flux sur une application webtwolol (parfois très soudain, avec 2 à 6 connexions simultanées par clients, des applications faisant généralement des traitements, etc). Et puis, personne n'a encore eu le mauvais gout de distribuer un serveur IMAP en javascript (à ma connaissance) :P
[^] # Re: Les adminsys en redemande
Posté par herodiade . En réponse à la dépêche Les technos web cools du moment. Évalué à 2.
Un protocole conçu pour ça, précisément, pas Hyper Text Transport "Quand j'ai un marteau tout ressemble à un clou" Protocol ;). Bon je reconnais que j'exagère, il y a surement lieu de s'inspirer du mail pour améliorer le web (y compris, peut-être, l'IDLE d'IMAP). Mais la situation est différente et beaucoup plus facile à gérer pour le mail :
o C'est éminemment, naturellement shardable / partitionable (à la différence d'une application appuyée sur une base de donnée relationnelle, les mailboxes sont des "data stores" très faciles à dispatcher et répartir). A l'opposé des prérequis pour la construction, par exemple, d'un graphe de réseau social. Voir à ce sujet les réflexions de James Hamilton, par exemple ici : http://perspectives.mvdirona.com/2008/06/08/ScalingLinkedIn.(...)
Ok, rien à voir avec le sujet de ce thread, mais en écho au thème des nouveaux systèmes de stockage NoSQL.
o Des questions de volumes et de dimensionnements (prévisibles ou pas). Le trafic (nombre de connexions) d'un serveur IMAP est généralement facile à anticiper, ou du moins suit des évolutions prédictibles; un trafic normalement limitée à l'ensemble des utilisateurs connus et enregistrés. Servis par un applicatif minimal et quasi non bloquant (hormis l'auth, presque de pures I/O). L'applicatif est en même temps directement le serveur de stockage. Naturellement asynchrone. Je ne crois pas qu'il y ai beaucoup d'environnement IMAP dans le monde qui ont l'occasion de recevoir 100 000 connexions simultanées, ni même 10k. Ca n'est pas tout à fait de même nature que les vagues de flux sur une application webtwolol (parfois très soudain, avec 2 à 6 connexions simultanées par clients, des applications faisant généralement des traitements, etc). Et puis, personne n'a encore eu le mauvais gout de distribuer un serveur IMAP en javascript (à ma connaissance) :P