Shuis pas fan de l'idée. Une URL donne une indication de ce que je vais y trouver, par son nom de domaine, mais aussi par son URL. Un raccourcisseur d'URL masque cette info. Sur l'exemple de ce matin, la totalité de l'histoire était déjà contenue dans le lien, limite ça ne servait plus à rien de lire l'article.
Et y'a certains domaines sur lesquels je ne veux pas aller, le raccourcisseur me masquerai cette info, donc j'irai quand même.

Le raccourcisseur est un outil, mais pas la solution à tout. Et en créer un lexpage, ça me semble inutile quand il en existe déjà tant ailleurs.

Je rejoins l'avis de Tchou concernant le raccourcisseur d'URL. Ce n'est pas complexe à mettre en place, mais je n'aime pas l'idée de "trop" masquer l'url, ni de dépendre finalement de ce service pour savoir "de quoi parle un lien" (le jour où le service est abandonné pour une raison x ou y, y a plein de liens qui seront non-fonctionnels. Y a moins de risque de voir bitly lacher que Lexpage ).

Je vais réfléchir à ta proposition, Tchou : celle de laisser le champ "relativement libre de taille", et ensuite de faire le découpage coté serveur. Je suis partagé, parce que le "minichat" est là pour des "mini messages", un peu comme les SMS par rapport aux e-mails. Si on veut "parler davantage", on utilisera les discussions du forum, par exemple. Donc d'un coté, je suis d'accord que 150 caractères, c'est un peu léger (qu'on peut "contourner" via plusieurs messages consécutifs), mais en même temps, cette restriction pousse à utiliser le forum (ou à ne pas utiliser le minichat) pour des messages plus longs. Par contre, je suis tout à fait d'accord que lorsqu'on colle une URL, on prend (trop) rapidement les caractères disponibles... (d'où sans doute l'idée d'Anca d'automatiser un raccourcissement des URL's).

Ou bien considérer que chaque lien ne prend qu'un caractère puisque c'est la taille que ça prendra à l'affichage. Ça revient à dire supprimer le maxlength html et recalculer ça en JS.

Ca rend le stockage dans la db délicat, surtout si un lien peut faire plusieurs centaines de caractères.
Mais oui, je pense qu'il faudrait s'orienter vers quelque chose de ce genre pour garder la limite et le coté "mini messages", tout en n'étant pas pénalisé par la présence d'une URL longue.

Si vous êtes intéressés par Docker + Windows:

https://digital.1105media.com/MSDN/2017/MDN_1704/MO_1704Q1_701922927.html#p=16

En vue du déploiement de la nouvelle version de Twicy, une mise à jour de Lexpage vers Django 2 va être déployée dans quelques minutes. Les batteries de tests ont résisté dans l'environnement de dev (après pas mal de changements, cela dit), on verra si l'environnement de prod va survivre N'hésitez pas à rapporter les éventuels bugs !

Sortie prévue de la nouvelle version de Twicy : courant 2028. Tenez-vous prêts
(Vous y avez cru, quand même, un tout petit peu, non ?)

[Edit : voilà, c'est fait]

Actuellement, Lexpage est distribué sous GPL3. Je me demande de plus en plus s'il ne serait pas judicieux que le site soit distribué sous AGPL. Je sais qu'on considère en général que GPL3 est la plus "libre et contaminante" des licences (y a BSD ou MIT ou ... pour être encore plus libre), mais dans le cas d'une "webapp" comme Lexpage, cela n'a pas beaucoup de sens de placer le code sous GPL et non sous AGPL.

Y a des "experts" en licence ici qui pourraient m'éclairer un peu ?

Si je passe en AGPL, il faudra soit que je laisse l'ancien code en GPL (les deux sont compatibles normalement, mais l'ancien code reste sous GPL), soit que je contacte chaque contributeur (il n'y en a pas tant que ça heureusement ) pour accord de passer l'ancien code en AGPL également.

[Edit : un lien pour AGPL pour ceux qui veulent en savoir davantage : www.gnu.org/licenses/why…]

[Edit : j'ai ouvert un ticket sur le dépôt GitHub également github.com/AlexandreDeca…]

Pas beaucoup de retours

Y a pas de libristes dans le coin ?