Re: Merci

Merci.

Pour répondre à tes deux points :

je me suis qu'à peine penché sur les bases de données orientées documents, je me suis toujours demandé si créer pleins de petits documents potentiellement liés entre eux était une bonne pratique. As-tu des info là dessus ? As-tu fais des tests avec Couch ?

Je me suis demandé la même chose et la réponse de la documentation dit que lorsque l'on arrive dans les millions ça commence à poser des problèmes. Pour ces cas extrêmes j'ai réfléchi au fait de pouvoir choisir la manière dont sont stockés les composants, et de les embarquer dans un seul document dans un champs, disons, components. Je pense qu'en fait le cas d'usage influe beaucoup sur ce qui fait sens. Dans un premier temps pour \BlueLaTeX j'ai privilégié l'approche qui réduit les conflits. À vrai dire, les documents sont liés entre eux de manière assez simple et les vues nécessaires pour les gérer le sont aussi, notamment, il n'y a pas de fonction reduce, mais uniquement un index des composants par entité et par type. Le protocole entre CouchDB et le server de query est particulièrement mauvais pour les fonctions reduce en l'état, un meilleur protocole est en cours de développement et devrait améliorer les latences. Je n'ai pas remarqué de lenteurs particulières, et des utilisateurs de sohva m'ont fait part de bonnes performances même avec des bases assez chargées. Si les vues peuvent être construites de manière incrémentielle, et que l'on ajoute les données au fil de l'eau, alors le temps passé à construire les vues est aussi mieux réparti et ne se fait pas trop sentir. Le cas des entités dans sohva doit rentrer dedans. J'avoue que je n'ai pas fait de tests de limites pour le moment, c'est toujours en développement mais je vais le planifier :)

je n'ai pas bien compris où se trouve le document. Tu montre des composants qui représentent des bouts logique de document (faire une rotation, placer un texte à tel endroit). Tu as une surcouche à TeX/LaTeX ? Si oui cela ne pose-t'il pas problème (des limitation de la surcouche, des bugs dans le rendu TeX de celle-ci) ?

En fait les composants représentent les méta données d'un projet LaTeX du point de vue \BlueLaTeX. Les fichiers TeX quant à eux sont enregistrés normalement sur le disque dur et compilé sur le disque de manière tout à fait normale.
En base de données ne se trouvent que les données nécessaires à la gestion des permissions, des cycles de vie, des utilisateurs, etc... Typiquement le composant compiler d'un papier a cette tête là :

{
 "_id": "x1ef7eb26809749fb:compiler",
 "_rev": "1-b41dd8557bfe0f9ad73ce0334da2d2b3",
 "compiler": "pdflatex",
 "synctex": true,
 "timeout": 30,
 "interval": 1,
 "sohva-entities-type": "component",
 "sohva-entities-name": "gnieh.blue.compile.CompilerSettings",
 "sohva-entities-entity": "x1ef7eb26809749fb"
}

Et sert en quelque sorte de descripteur de build pour le papier avec l'id x1ef7eb26809749fb :

• compiler avec pdflatex
• générer les donnés SyncTeX
• le processus système timeout après 30 secondes
• et un intervalle d'au moins 1 seconde est imposé entre deux compilation
• le reste des champs est spécifique à la couche de gestion des entités

Si on regarde le composant core de ce même papier, on verra :

{
 "_id": "x1ef7eb26809749fb:core",
 "_rev": "1-a3602ca121f7f9f7a2990203543e98ee",
 "name": "test paper",
 "creation_date": "2014-08-24T14:21:33.382",
 "sohva-entities-type": "component",
 "sohva-entities-name": "gnieh.blue.couch.Paper",
 "sohva-entities-entity": "x1ef7eb26809749fb"
}

Qui contient la date de création et le nom donné par l'utlisateur à ce papier.

Bref, ce sont uniquement des meta données sur le papier, spécifiques à \BlueLaTeX, il n'y a aucune surcouche à LaTeX écrite pour ce qui est de la compilation des documents.

J'espère avoir clarifié les choses sinon hésite pas à demander :)