Personnellement je m'en fiche si quelqu'un essaye de me suivre via Lexpage. Cela ne dit pas à la personne si je suis chez moi, sur mon mobile ou ailleurs encore...

roidelapluieJe n'ai pas dit mon dernier mot sur l'ordre du minichat

Il faut qu'on y réfléchisse, parce que c'est vrai que les "blocs messages" ne sont pas cohérents pour l'instant. On devrait inverser l'ordre au sein de ces "super-messages", vu qu'ils sont présentés comme "un seul et unique". Le "hic", c'est que le regroupement peut se faire à plusieurs heures d'intervalles... Peut-être ne devrait-on regrouper que les messages distants d'au maximum quelques minutes (ou max une heure ?) et inverser leur ordre à l'affichage ?

(RDLP> Je reste partisan que le "groupage" soit fait dans la vue json, et que la template se contente d'en afficher l'ordre. Il s'agit bien de logique d'organisation des données, et non pas simplement d'un rendu à faire à l'écran)

roidelapluieAvez vous une remarque sur l'éventuelle implication dans votre vie privée?

Ne pas oublier que les "en ligne" ne sont visibles que par les utilisateurs inscrits et identifiés !

GuybrushJe reste partisan que le "groupage" soit fait dans la vue json, et que la template se contente d'en afficher l'ordre. Il s'agit bien de logique d'organisation des données, et non pas simplement d'un rendu à faire à l'écran

Tu saurais essayer de présenter un POC ? ça revient vraiment à faire un grand écart avec Django Rest Framework et je ne vois pas par quel bout le prendre.

Je regarde à cela. On n'est pas obligé de le faire dans DRF, on peut aussi le faire en JS après avoir reçu le listing des messages, juste avant de passer ça à la template. Le code sera grosso-modo le même (mais en JS au lieu de Python) ^^.

C'est surement mieux, aussi pour les gens qui utilisent l'API rest. Ils feront ce qu'ils veulent comme rendu (et oui pour moi c'est du rendu et pas de la logique )

github.com/AlexandreDeca…

Et je vomis sur JS (je déteste vraiment ce "langage" !!)

Au fait, on peut parler de l'ordre d'affichage des archives du mini-chat (oui, la page où personne ne va ) ?

Actuellement, l'ordre chronologique y est de bas en haut, et là, ça me paraît bizarre. J'ai deux arguments:
- en principe on va pas dans les archives pour voir les dernières news, il n'est donc pas nécessaire de mettre les dernières conversations en haut,
- dans les archives du forum, les discussions sont triées par ordre de date de premier message croissante (donc l'ordre inverse de celui qui est utilisé dans la page d'accueil), je pense qu'on peut appliquer ce principe aux archives du mini-chat.

Je suis d'accord. On doit repasser sur la manière d'afficher les archives du minichat. Pour l'instant, ce n'est pas encore clair pour moi si on va proposer des archives (comme actuellement, mais triées et ordonnées autrement), si on va proposer un "grand minichat" permettant de remonter aussi dans le temps, ou si on va proposer les deux.

Je copie-colle ton message sur GitHub (#166) pour garder une trace quand on s'attaquera à ça :)

Alors, j'ai une question un brin conne. Est-ce que le websocket a une durée maximale d'activité de la connection, ou tant que 3 heartbeats n'ont pas été reçues il persiste ? (j'ai regardé en diagonale le source, j'ai vu que ça apparemment).

Je pose la question car je me suis aperçu récemment que mon téléphone avait sa batterie qui fondait à vue d'œil, avec comme cause probable le browser, et comme un des deux onglets ouverts cette page-ci (la lex). Or dans android, un retour vers home ou un précédent ne kill pas l'appli, il la minimise "juste" (si je réouvre, ça s'affiche immédiatement dans la page où j'étais).
J'ai réessayé de revérifier, j'ai rebooté, chargé la batterie full, intentionnellement ouvert que sur lexpage et laissé une journée sans retoucher au browser, la batterie s'est vidée à peu près normalement, mais moz est quand même assez haut sur la barre de conso, plus que pour juste l'affichage initial d'une page.

Je n'en ai aucune idée, roidelapluie pourra peut-être te répondre.

Mais je suis actuellement en train de réfléchir pour ne plus utiliser le websocket (notamment parce que ça me pose d'énormes soucis avec les tests Selenium). Ces tests (qui foirent souvent sans raison) me poussent de plus en plus à reconsidérer l'intégration des WS sur Lexpage.

En attendant HTTP 2, j'envisage de plus en plus une solution hybride à base de pooling régulier (comme l'ancien minichat, sauf qu'ici, le pooling irait interroger le serveur pour connaître les événements (privés ou publics) écoulés depuis le dernier pool, et on aurait donc une approche centralisée utilisable pour n'importe quel composant du Lexpage, avec un pooling par exemple toutes les 5 ou 10 secondes (en utilisant les entêtes HTTP, on peut sans doute éviter beaucoup de trafic inutile et n'envoyer l'information que quand nécessaire).

J'attends un retour de RDLP (discussion privée) pour voir s'il a une autre approche pour régler le souci actuel des tests/WS, et puis j'aviserai sur cette possibilité.

Petite mise à jour discrète avec l'inversion de l'ordre des messages du minichat quand les messages sont "collés". Le "collage" se fait par auteur et par délai : si vous postez plusieurs messages séparés de moins de 5 minutes, ils sont regroupés en un seul et sont affichés dans l'ordre "naturel" (donc inverse du minichat).

Si vous êtes la cible d'un @username, il sera aussi mis en gras pour vous permettre de le retrouver plus facilement.

Les messages "nouveaux" sont affichés avec une bordure rouge. Par "nouveau", on entend ceux qui ont été posté depuis le chargement de la page précédente (le statut "nouveau" ne s'actualise PAS avant la page suivante, c'est donc normal d'avoir encore des messages "rouges" si vous avez posté quelque chose ou que vous avez ouvert un autre onglet dans lequel ces messages ne sont pas étiquettés "nouveaux").

Ce n'est pas 100% idéal, je réfléchis à une meilleure approche, mais je voulais pousser ces modifications en prod rapidement pour me concentrer sur un refactoring bien plus important.