Joack a écrit 13 commentaires

C'est une façon intéressante de résoudre les bugs de multi-threading :)

J'ai jamais dit que c'était une façon de régler la chose, j'ai juste dit que la possibilité qu'un tel événement se produise est (très) faible. Et c'est pour ça que je travaille sur un patch pour régler le problème au cas où il se rencontre :)

Tu aurais parlé de bugs d'accès concurrent, j'aurai compris mais je ne vois pas ce que vient faire le multi-threading dans la donne.

Mouais. Vaudrait mieux s'y pencher avant que le bug apparaisse chez des utilisateurs, AMHA.

Oui enfin vraiment rapide c'est de l'ordre de microseconde donc la possibilité que deux dumps se croisent et tout de même assez faible.

Mais c'est vrai que techniquement ça peut arriver, je vais faire une release pour corriger le bug, merci de l'avoir relevé.

Ce n'est pas une question bête du tout et c'est vrai que je ne me suis pas penché dessus, après le temps de dump dans un fichier est vraiment très rapide même dans un fichier assez important.

Après ça reste possible techniquement et ça n'est pas géré encore par l'application. Mais il existe des bibliothèques pour les accès concurrents en Python, c'est une piste à étudier.

J'ai du mal à comprendre la polémique autour de la non utilisation d'outil relationnel là où on en pas forcément besoin.

Plus que la dépendance de SQLite qui est compris de base avec Python 2.5+, à moins de se taper du code sql et alourdir un peu plus le code, viennent au moins les dépendances des ORM.

Il ne s'agit pas forcément ici de faire une croix sur les dépendances en pur Python comme tu dis mais de choisir l'implémentation de la sérialisation d'objets. Dans mon cas j'ai choisi le stockage par fichiers car je ne voyais pas forcément l'intérêt du relationnel.

Je ne remet pas en doute l'intérêt du relationnel dans certains cas, mais comme il a été déjà dit précédemment à chaque besoin sa solution.

Quant aux gains de perf de cette solution je t'avoue ne pas avoir fait de réels tests mais vu que les fichiers ne sont rechargés en mémoire que s'ils sont modifiés et non à chaque requête dessus, j'aurai tendance à dire que le modèle relationnel dans ce cas utilise plus de mémoire. Après je me trompe peut être et la solution relationnelle aurait été la meilleure ici.

L'application n'a effectivement pas besoin de base de données.

Concernant les serveurs, elle embarque bien un serveur WSGI dont il n'y a pas besoin de s'occuper mais pour le déploiement il lui faut bien un serveur web (Apache, Nginx, Lighttpd, …).

A partir de la, sqlite n'apporte que du bonus par rapport à mes besoins, ca permet d'implémenter facilement ce que Yohann suggère par exemple.
…
Concernant le formatage sur le relationnel, je suis d'accord, mais je bosse aussi tous les jours avec du nosql, et je comprends ceux qui reviennent sur du relationnel. Ca a beau être old school, ca sait faire un group by correctement au moins.

On parle aussi de Python ne l'oublions pas, qui apporte des possibilités telle que les compréhensions de liste qui peut très bien faire un group by sans autres dépendances.

Peux tu préciser ta pensée parce que c'est un peu flou pour moi tout de suite ?

Pour revenir sur le SQLite sinon, il est vrai que je voulais un maximum éviter les bases de données et autres dépendances non nécessaires.

Même s'il est vrai SQLite reste un poids plume des bases de données les impératifs de l'application ne le rendaient pas forcément indispensable.

La doc a été enrichie d'une partie concernant l'utilisation en elle même du logiciel avec quelques captures d'écran.

http://microbe.joacodepel.tk/admin.html

Il s'agit encore d'un premier jet visant à être complété par la suite.

Effectivement la partie configuration de la documentation n'étant pas encore finalisée, je ne l'avais pas encore mis en ligne. Je n'avais pas réalisé que les codes d'accès se trouvait dedans.

Concernant les liens cassés il s'agit d'un soucis concernant le Server name dans la partie configuration. L'application se sert de lui pour construire les urls, je n'ai pas pris en compte la possibilité qu'il soit vide.

Concernant la partie SQLite, je ne pense pas forcément que ça ne m'aurait apporté beaucoup plus d'avoir du relationnel.

Effectivement la documentation doit encore être étoffée.

Cependant concernant la partie où les fichiers ont besoin d'être déposé, l'application s'en occupe pour toi. Tous les nouveaux contenus se créent directement depuis l'interface d'administration du logiciel.

Le but premier du logiciel étant d'être configurable exclusivement depuis l'interface pour une facilité d'utilisation maximale.

Techniquement parlant les fichiers de contenu contiennent une partie en Markdown pour le contenu et une partie Yaml pour les informations diverses qui les concerne (tags, catégorie, auteur, …).

C'est dans cette partie que sont conservés les commentaires.

Les fichiers sont chargé en cache une fois créé, ensuite ils sont rechargés à chaque fois qu'ils sont modifiés.

DaCode demande l'installation d'une base MySql ou Postgres si je ne m'abuse.

Ce n'est pas le cas ici.

• installation : pip install microbe
• lancement : microbe

Et c'est tout.

Ca fait plaisir de voir que l'initiative plait.

Concernant la démo effectivement ce serait quelque chose à envisager dès que j'aurai un peu de temps.

Comme déjà expliqué Pelican permet à base de templates de générer des pages statiques.

Microbe va gérer tes pages de façon dynamique, ce qui va apporter un certain nombre de fonctionnalités en plus :

• Pouvoir depuis une interface ajouter/modifier/supprimer du contenu et les modifications prendront effet automatiquement.
• Pouvoir faire une recherche sur les articles du site sans passer par un moteur de recherche externe.
• Pouvoir ajouter des commentaires à un articles sans passer par une lib tierce en JavaScript.

La configuration du site (thème, langue, liens, …) est également modifiable directement depuis l'interface web, plus besoin de passer par un éditeur pour aller modifier ton fichier conf.py.