Centralisation de la gestion des autoblogs

[ArthurHoaro]

Pour la 0.4, avant de s'attaquer à la partie d'administration, je propose de centraliser la gestion des autoblogs.

C'est à dire :

• Création d'une DB SQLite contenant l'équivalent de tous les vvb.ini.
• On conserve le système d'une DB/autoblog.

Cela permet de grandement simplifier et uniformiser la gestion d'une interface d'administration. Par contre, ça demande pas mal de changement de code, je pense.

Autre point à discuter : est-ce qu'il vaut mieux conserver le système des index.php dans chacun des dossiers, ou est-ce que ça ne serait pas plus simple d'avoir un fichier qui gère l'affichage à partir d'une variable GET ?

EDIT : Ca veut aussi dire tout casser à nouveau. :/

[mitsukarenai]

Yep, ça me semble bien appartenir à une 0.4 car à ce stade autant réécrire proprement tout le code :) Le fonctionnement serait aussi beaucoup trop différent par rapport aux versions précédentes.

Concrètement ça ferait ça ?
dans /autoblogs, toutes les bases SQLite des autoblogs
dans /autoblogs/media, tous les fichiers média des autoblogs
dans /, une base SQLite "index.db" reprenant la fonction des vvb.ini
dans /, un fichier "index.php" qui traite la base de l'autoblog demandé, ou à défaut se contente de lister les autoblogs disponibles
dans /admin un panneau de gestion manipulant "index.db" voire carrément les fichiers média et les bases des autoblogs (s'il faut supprimer un truc par ex)

Mmmmoui jusque là c'est pas du genre à faire de noeuds au cerveau, sauf peut-être la partie authentification pour le panneau d'admin (reprendre celui de shaarli ?)

[ArthurHoaro]

Ca serait quelque chose du genre oui. Laissons pour l'instant l'admin de côté, mais je pense que ça sera plus un fichier qu'un dossier. Et il faudra effectivement faire quelque chose dans le même goût que l'authentification de Shaarli. De toute façon, avec une authentification en mode fichier, on n'a pas trop de choix.

Pour les medias, je pense qu'il faut conserver une arborescence d'un dossier par autoblog, sinon on risque un peu de s'arracher les cheveux pour la suppression.
Sinon c'est à peu près ça oui. Je garderais peut être bien une séparation liste autoblogs / affichage d'un autoblog sur deux fichiers pour éviter de rendre le code illisible... C'est à voir. :)

Pour le fait de conserver le système des index.php dans chacun des dossiers ou d'avoir un fichier qui gère l'affichage à partir d'une variable GET, je propose l’usage de symlinks !
Parce que bon, avoir une page par autoblog est selon moi meilleur dans l’idée de sémantique du web « une page = une ressource = une information », et d’éviter de faire comme ces sites web qui mettent tout le site dans /index.php avec tout qui est appelé via des variables GET… Je trouve ça ignoble…

Après je comprend la volonté de vouloir économiser des fichiers et simplifier en enlevant les répertoires multiples pour chaque autoblog dans /autoblogs, mais je considère qu’il faut quand même un fichier par autoblog… Et comme l’a mentionné ArthurHoaro, il faudra bien garder au moins un répertoire par autoblog, puisque mettre touts les média au même endroit rendra la gestion de ceux-ci cauchemardesque.

Donc :
/index.php : page d’accueil avec index des autoblogs ;
/index.db : index des autoblogs sous forme de base SQLite ;
/admin.php : page d’administration qui propose des fonctions de suppression, ajout (indépendamment de ce qui est publiquement autorisé), etc. ;
/autoblogs/ : ensemble des autoblogs (base vvb.db + médias), avec un répertoire par autoblog (comme maintenant).

Btw, pourquoi diable le répertoire de chaque autoblog est-il si cryptique ? Pourquoi faire un hash ? Pourquoi retirer les points des noms de domaines ? De belles URL simples sont plus faciles à retenir (et à lire, et à écrire, et plaisent plus au bots de Google qui font attention à ce genre de choses).

[ArthurHoaro]

C'est pas con les symlinks ! Je pose quand même deux points d'attention lorsque l'on prendra la décision :

1. Etre sûr que 200 liens symboliques vers la même ressource ne posent pas de problème de performance.
2. Les serveurs web les acceptent ou non selon leur configuration : ça rajoute une contrainte.

Mais finalement avec la DB centrale, il suffirait avoir un autoblog.php qui gère tout ça en GET. Ca permettrait d'avoir des URL du genre :

• http://autoblog.domain.tld/autoblog.php?q=1

ou

• http://autoblog.domain.tld/autoblog.php?q=1-hoa.ro

Ca permet également l'URL rewriting.

Il existe autant de programmeurs que de façons de coder.

J’aime pas beaucoup l’idée d’autoblog.php central qui gère tout en GET… Comme déjà dit précédemment : une page = une ressource.
« Parce que bon, avoir une page par autoblog est selon moi meilleur dans l’idée de sémantique du web « une page = une ressource = une information », et d’éviter de faire comme ces sites web qui mettent tout le site dans /index.php avec tout qui est appelé via des variables GET… Je trouve ça ignoble… »

Pour les liens symboliques c’est en effet une contrainte : touts les serveurs les gèrent pas, toutes les configurations ne le gèrent pas, touts les systèmes de fichiers ne les gèrent pas et touts les OS ne les gèrent pas.
Et ça rendrait le truc juste un tout petit peu riquiqui plus rapide, rien que ça…

Quand au « 200 liens symboliques vers la même ressource » : actuellement avec un include PHP, ça doit pas poser plus de problèmes, et ça pourrait éventuellement en causer moins.

Pour reprendre ce que je disais dans l’issue #65 :

Il faudrait changer le nommage des répertoires des autoblogs : le hash n’assure pas bien l’unicité, rend l’URL trop longue, peu lisible, cryptique/repoussante pour certains (btw le bot de Google favorise le sémantique, la clarté, la légèreté, la simplicité, et bref : ne risque pas d’aimer ces URL).
On pourrait utiliser l’URL du blog (l’URL du RSS n’étant pas unique : typiquement le cas RSS/Atom), mais comme l’a fait remarqué ArthurHoaro sur l’issue précédemment citée, certains flux RSS pointent sur la même URL de site (typiquement le flux des articles et celui des commentaires de touts les articles). Ainsi il faudrait parfois changer le nom du répertoire…
Je propose alors qu’on puisse ajouter un champ « nom de répertoire de l’autoblog », par opposition au « nom canonique de l’autoblog », qui puisse être changé à l’ajout (et dont le changement est requis si un autoblog a déjà un tel nom de répertoire).

Il faudrait également plus de vérification sur les URL : tester l’URL du flux (pour évider un autoblog vide, mais laisser la possibilité de l’ajouter quand même, au cas où là maintenant le blog soit inaccessible mais qu’il puisse l’être de nouveau plus tard), tester l’URL du blog (idem), tester l’HTTPS (s’il est dispo autant l’utiliser par principe de cryptoanarchie), tester si l’URL contient quelque chose d’inutile à la fin comme « # », « ? » ou « #? », etc.

J’aurais aussi une demande concernant la remise en question de l’absolue nécessité de AUTOBLOGS_FOLDER : ça rend l’URL plus longue, et c’est pas forcément plus simple et pratique.
Dans l’issue #20 il était dit : « Bon déjà, il faut garder le sous-dossier AUTOBLOGS_FOLDER, c'est bien plus simple et propre. », sauf que ça dépend du point de vue : externe ou interne ? Du point de vue externe c’est plus simple et plus propre (et le nommage actuel paraît inutilement compliqué et long), du point de vue interne c’est gérable (pour lister ce qui est important d’autre que les autoblogs : /*.php et /resources/, c’est tout, en ligne de commande, pas besoin d’un répertoire supplémentaire), donc autant y réfléchir ^^.

[ArthurHoaro]

actuellement avec un include PHP, ça doit pas poser plus de problèmes

Effectivement, je n'y avais jamais pensé.

ajouter un champ « nom de répertoire de l’autoblog » [...] qui puisse être changé à l’ajout

J'aime bien l'idée. Et je pense même qu'on pourrait faire un système du genre :

• un ID numérique qui s'incrémente et garanti l'unicité
• un nom qu'il est possible de renommer, comme tu le propose, pour la sémantique

tester l’URL du flux

C'est déjà le cas normalement.

tester l’HTTPS

Dans notre cas, HTTPS n'apporte pas grand chose et ça fait des requêtes en plus. Je ne vois pas trop l'intérêt.

tester si l’URL contient quelque chose d’inutile à la fin comme « # », « ? » ou « #? »

Yep.

remise en question de l’absolue nécessité de AUTOBLOGS_FOLDER

Crois moi, quand tu développes l'outil avec XSAF, et que tu cherches ton .php dans l'IDE au milieu de 150 autoblogs, tu es content d'avoir un sous dossier. D'autant que ça ne change pas grand chose pour l'URL. S'il te gêne, mets un dossier d'une lettre dans la variable AUTOBLOGS_FOLDER.

Argh, l’ID incrémenté, ce serait pas mieux que le hash : ’fin ce serait vraiment unique, mais bon à ce niveau le hash ya peu de probabilités de collisions et ça permet l’unicité des URL de flux RSS (même si ça garantit pas l’unicité d’autoblogs).
Le nom possible à renommé me semble une excellente idée du coup :) et je suis heureux que l’idée soit appréciée =D

L’HTTPS est utile pour une question de cryptoanarchie : plus on chiffre les communications, plus le fait de chiffrer est banal, moins c’est suspect, et moins les gouvernements et tout programme de surveillance généralisée ont de pouvoir. Si le fait que ce soit plus lent ou que ça fasse des requêtes supplémentaires te dérange, on pourrait le mettre en option avec un booléen dans le fichier de configuration.

Pour AUTOBLOGS_FOLDER, c’est dommage de devoir adapter l’usage à l’outil plutôt que d’adapter l’outil à l’usage… c’est dommage de voir ça en informatique… Surtout qu’une IDE qui liste tout même ce qu’on veut pas qu’elle liste, bah (si je cite emacs, on va se plaindre qu’on est pas vendredi)… Puis bon les *.php yen a à peine 3/4, c’est pas énorme, pas besoin de les chercher quoi, suffit d’écrire un peu (avec l’autocomplétion c’est à peine quelques lettres). Meuh bon, après c’est vous qui voyez… Je trouve ça juste dommage (la perspective d’avoir un seul sous répertoire, quelque chose comme autoblog.domain.tld/reflets.info est si alléchante… meuh bon c’doit être du pinaillage pour vous ^^").
Ou alors peut-être avec de la réécriture d’URL/redirection…

Bon, touts les autoblogs fonctionnent pareil, et ont les mêmes caractéristiques stockées, quel que soit le type : redondance, ça développe trop le code, ça rend le fonctionnement assez rigide, l’export problématique…

Le problème concerne la spécialisation et l’optimisation des différents types d’autoblogs : minimiser les caractéristiques stockées. Genre pour twitter : seul le nom du comte, le type « twitter » et une description tirée de twitter suffit. Pour les microblogs statusnet/pump.io/GNU Social : idem mais avec l’URL de l’instance en plus. Pour un blog normal faut l’URL du flux RSS, le titre donné par le flux RSS, l’URL de la page principale donnée du blog par le flux RSS et la description donnée par la balise « <meta name="description" value="[…]" /> » de la page principale du blog. Le fait est que l’on déduirait tout de ce minimum d’informations. Par exemple on ne devrait pas utiliser une URL de flux RSS pour chaque compte twitter, mais le pont d’où récupérer les tweet serait choisit en fonction de la configuration actuelle : si je change la configuration, je peux décider qu’ils vont êtres cherchés sur le flux RSS de twitter, sur un flux produit par le script local, sur un pont perso, ou sur le pont de quelqu’un d’autre, et ils seraient à partir de là tous pris ainsi. On ne metterait pas de variable « titre » pour les autoblogs twitter non plus, puisqu’il peut être construit à partir du type et du nom du compte « Twitter — <user_id> »
Parce qu’actuellement j’ai une trentaine d’autoblogs qui vont chercher les tweets sur le(s) pont(s) de suumitsu.eu (et de hoa.ro) : dépendance, perte d’autonomie… Mais ils sont tous indiqués dans chacun des vvb.ini… C’est mieux de faire en fonction de la configuration courante plutôt que de celle au moment de la création : factorisation, flexibilité, etc.

Il faudrait faire pareil avec Youtube, et les microblogs.
Et comme ça quand les spécifications de Statusnet, Pump.io ou GNU Social changent, le fonctionnement étant plus factorisé, on pourrait mettre à jour plus facilement et l’export serait plus efficient.
Du coup on pourrait avoir juste un menu déroulant, avec : Twitter (pont local par défaut, changeable selon la configuration), Youtube (RSS de Youtube), Statusnet (développement arrêté, interface figée), Pump.io (reste, ou a été, compatible statusnet, pour aider la transition, non ?) et GNU Social (avec lequel statusnet a été mergé a son abandon, donc compatible avec celui-ci). À cela on pourrait ajouter une ligne d’édition, valable pour Statusnet, Pump.io et GNU Social, où on indiquerait l’URL de base de l’instance (prérempli avec l’instance la plus utilisée : genre identi.ca par défaut, mais avec du JS on pourrait en mettre un autre quand on change d’implé’ de microblog pour GNU Social par exemple).

Oh, et maintenant que j’y pense : du coup on pourrait changer radicalement le nommage des répertoires des autoblogs, pour rendre le tout plus lisible, et régler par la même occasion le problème de ce « répertoire inutile » qui me dérange tellement (^^") sans alourdir / !
On pourrait faire 7 répertoires à la racine : /blogs (autoblogs par défaut avec un fichier RSS, Atom ou OPML) /shaarli (instance de Shaarli), /twitter (compte Twitter), /youtube (compte Youtube), /social (compte d’une instance GNU Social), /status (compte d’une instance statusnet) et /pump (compte d’une instance pump.io) ! Pour ce qui a différents comptes sur plusieurs instances (statusnet, pump.io, GNU Social), on pourrait faire un répertoire par instance (ça permettrait de classer par instances, et de proposer des instances à l’ajout d’un compte de microblogging), genre /pump/identi.ca/ pour identica !
Ainsi on pourrait avoir /blogs/sebsauvage.net%2Frhaa, /shaarli/sebsauvage.net%2Flinks, /youtube/sebsauvagenet, /twitter/mitsukarenai, /pump/identi.ca/misukarenai, /social/status.vinilox.eu/schoewilliam, /status/status.ndn.cx/gordontesos, etc.

Je trouve que c’est une organisation simple, belle, fonctionnelle, et qui prend bien en charge l’unicité (tant qu’on peut redéfinir le nom des répertoire basés sur une URL et non un compte, comme dans /blogs, ou les instances dans /status, /pump ou /social).
En effet, ça évite déjà les doublons de comptes twitter : ce qui est complètement absurde, car si Twitter a un avantage c’est la centralisation qui lui permet de définir des identifiant simples et globaux, avoir des doublons est insensé, puisque les identifiants twitter sont déjà uniques. Actuellement je peux avoir un « Twitter - mitsukarenai », un « twitter-mitsukarenai », mais aussi un « Twitter-mitsukarenai », un « twitter - mitsukarenai » et puis un « Twitter — mitsukarenai » (ya au moins 8 possibilités de nom rien que là), sans compter l’infinité flux différents possible pour chaque autoblog twitter (provenant de plusieurs ponts, 2 à suumitsu.eu, 1 à hoa.ro, etc. ce qui explique que j’ai des comptes twitter répliqués 5 fois, sans utiliser de tiret sur quadratin « — »).
Il en est de même pour identica, et les microblog en général : la syntaxe globale est suffisamment rigoureuse pour éviter les doublons avec un système <instance>/<identifiant>.
Le seul doublon possible vient du fait que les URL peuvent avoir une limite de longueur ou être les mêmes avec deux feeds différents qui pointent dessus (ça ça concerne que les blogs, pas les microblogs), et donc être tronquées/modifiées différemment, ainsi le pire possible et d’avoir un doublon pour un blog ou une instance de microblog, mais c’est très simple à régler (et avec un peu de rigueur ça n’arrive jamais).