Avec Lexpage, c'est sans dérapage
—
meldja
Discussions
Lexpage (enfin) sur GitHub !
Une mise à jour du Lexpage a été déployée. Pour la partie visible, il s'agit essentiellement d'une refonte des archives du minichat pour avoir un rendu plus proche du "vrai" minichat. A noter que si vous recevez une notification impliquant un message du minichat, et que vous cliquez dessus, le message sera mis en évidence sur la page des archives.
Le système n'est pas encore parfait (notamment au niveau des flags de lecture), mais c'est mieux que rien.
Le changement moins visible, c'est la suppression des websockets. Roidelapluie m'en veut certainement d'avoir fait machine arrière par rapport aux WS, mais j'ai trop de "mal" à gérer tout ça et à m'assurer que ça ne sera pas un problème de maintenance le jour où RDLP ne met plus les mains de le cambouis du Lexpage (des histoires impliquant Selenium aussi ^^).
L'alternative est plus proche de l'ancien système que des WS : il s'agit d'un pooling à intervalle régulier, à la fois pour les notifications et le minichat. Le délai est assez court : 10 secondes environ, mais un système de cache à base d'ETag est en place, ce qui (1) évite de recharger trop souvent le minichat si rien n'a été changé (il y a un cache basé sur Redis qui s'adapte dès qu'un message/notification est modifiée pour un utilisateur, et l'ETag est généré sur base de cette valeur, invalidée au bout de 60 secondes max) et (2) évite de regénérer de l'HTML à la volée si le contenu n'a pas changé (ce qui devrait limiter l'usage de la batterie de vos mobiles !).
A coté de ça, de petits changements :
- Le code JS du minichat et des notifications est complètement revu, plus simple à maintenir et à organiser (pour les amateurs, ils iront voir sur Github).
- Les notifications en rapport avec le minichat ont leur texte qui s'adaptent au cas où le message concerné est modifié par l'utilisateur (ce qui ne peut être fait que pendant les 5 premières minutes).
Important : le système de cache actuel pour le minichat et les notifications ne fonctionnent pas. Ne vous étonnez donc pas d'avoir un pooling retournant du 200 au lieu de 304 en permanence. Visiblement, Nginx retire l'entête ETag dès qu'il active la compression de la page. Je travaille dessus, mais il va me falloir probablement gérer ça au niveau de Django car Nginx ne semble pas pouvoir être configuré pour arrêter de se mêler de ce qui ne le regarde pas
Le système n'est pas encore parfait (notamment au niveau des flags de lecture), mais c'est mieux que rien.
Le changement moins visible, c'est la suppression des websockets. Roidelapluie m'en veut certainement d'avoir fait machine arrière par rapport aux WS, mais j'ai trop de "mal" à gérer tout ça et à m'assurer que ça ne sera pas un problème de maintenance le jour où RDLP ne met plus les mains de le cambouis du Lexpage (des histoires impliquant Selenium aussi ^^).
L'alternative est plus proche de l'ancien système que des WS : il s'agit d'un pooling à intervalle régulier, à la fois pour les notifications et le minichat. Le délai est assez court : 10 secondes environ, mais un système de cache à base d'ETag est en place, ce qui (1) évite de recharger trop souvent le minichat si rien n'a été changé (il y a un cache basé sur Redis qui s'adapte dès qu'un message/notification est modifiée pour un utilisateur, et l'ETag est généré sur base de cette valeur, invalidée au bout de 60 secondes max) et (2) évite de regénérer de l'HTML à la volée si le contenu n'a pas changé (ce qui devrait limiter l'usage de la batterie de vos mobiles !).
A coté de ça, de petits changements :
- Le code JS du minichat et des notifications est complètement revu, plus simple à maintenir et à organiser (pour les amateurs, ils iront voir sur Github).
- Les notifications en rapport avec le minichat ont leur texte qui s'adaptent au cas où le message concerné est modifié par l'utilisateur (ce qui ne peut être fait que pendant les 5 premières minutes).
Important : le système de cache actuel pour le minichat et les notifications ne fonctionnent pas. Ne vous étonnez donc pas d'avoir un pooling retournant du 200 au lieu de 304 en permanence. Visiblement, Nginx retire l'entête ETag dès qu'il active la compression de la page. Je travaille dessus, mais il va me falloir probablement gérer ça au niveau de Django car Nginx ne semble pas pouvoir être configuré pour arrêter de se mêler de ce qui ne le regarde pas
Le nouveau système de cache est prêt et passe les tests. Par contre, y a un vieux bug idiot dans Firefox que j'aimerai contourner. En gros, quand on renvoie un 304 ("non-modifié"), Firefox essaie de parser le contenu de la réponse (typiquement, vide !) avec le parseur correspondant au content-type de la requête (vu que la réponse ne définit aucun contenu, donc aucun content-type). Or, par défaut, XMLHttpRequest, bah c'est du XML, et donc il fait une erreur "Aucun élément trouvé" sur le data de 0 octet. Ouais, il est con Firefox par moment 
Donc je dois contourner la génération automatique des 304 pour injecter un contenu inutile et forcer le content-type à text/html. Normalement, c'est bon (au moins en local). Je lance les tests, puis je m'attaque au bug signalé par Tchou sur les mobiles, je confirme que ça ne marche plus.
Donc je dois contourner la génération automatique des 304 pour injecter un contenu inutile et forcer le content-type à text/html. Normalement, c'est bon (au moins en local). Je lance les tests, puis je m'attaque au bug signalé par Tchou sur les mobiles, je confirme que ça ne marche plus.
Oui, je vais faire ça dès que j'ai du temps, c'est une bonne idée.
C'est hérité de l'ancien affichage des billets, il faudrait que je retire ça
C'est hérité de l'ancien affichage des billets, il faudrait que je retire ça