Sommaire
Allez, je me fends de mon premier journal pour vous présenter un projet qui m'occupe pas mal depuis quelques années, à l'occasion de la première version bêta publique de \BlueLaTeX, disponible sur la page des releases.
Mékeskecé ?
\BlueLaTeX est tout simplement une plateforme d'édition collaborative de documents en \LaTeX.
Le projet consiste en plusieurs modules :
- le gestionnaire d'utilisateurs et de documents,
- le serveur de synchronisation de fichiers,
- le serveur de compilation des documents,
- un client web
- …
Je reviendrai sur les différents modules par la suite, mais voilà globalement la structure du projet.
Une instance d'une ancienne version de \BlueLaTeX est hébergée et utilisable sur publications.li.
La version bêta ne devrait pas tarder à y être disponible en test.
Historique
Le tout premier prototype de \BlueLaTeX a été écrit par Martin en 2010 afin d'explorer l'idée d'un éditeur collaboratif en temps réel de documents en \LaTeX.
Ce prototype était écrit en php, le serveur de synchronisation mobwrite en python, et le client utilisait prototype.
L'idée était de créer facilement un document \ĻaTeX et de partager un simple lien entre les différents auteurs du document pour travailler dessus.
En 2011, le prototype est amélioré pour ajouter une interface Rest plus propre séparant clairement la livraison du contenu du client de la logique de gestion des documents.
Le client pour sa part abandonne prototype pour YUI, le serveur est resté fidèle au php avec une utilisation intensive de RewriteRule.
J'ai commencé à y mettre mon grain de sel début 2011, mais je n'aimais pas le php.
J'ai donc effectué un lobbying pour utiliser autre chose et début 2012, le serveur est enfin entièrement réécrit en scala et fonctionne.
Cette nouvelle version n'expose qu'une interface Rest et ne s'occupe pas du tout de l'application web, décorrélant la logique du client.
Le but est d'avoir un serveur qui peut être utilisé par n'importe quel client qui parlerait correctement à l'interface.
Un nouveau client est réécrit par Martin en GWT, ni lui ni moi n'étant spécialiste de javascript.
La synchronisation est toujours effectuée par mobwrite à qui le serveur délègue les requêtes.
Cette version est celle qui tourne depuis 2012 sur publications.li.
Tout au long de ces générations du service, une ligne directrice s'est précisée pour Martin et moi même : fournir une plateforme d'édition collaborative, d'accord ! Mais une plateforme qui cible en premier lieu les publications scientifiques.
De nouveaux concepts sont donc venus se greffer, rendant la maintenance du code un poil difficile.
Mi 2013, nous avons donc entamé une réécriture complète du serveur, toujours en scala, avec une architecture modulaire permettant de séparer les concepts proprement, et de fournir une API propre et claire.
Le code du serveur de synchronisation tenant plus du prototype que du code à mettre en production (notamment beaucoup de choses codées en dur), nous décidons de le réécrire.
La théorie de Neil Fraser très intéressante mais le protocole est assez rudimentaire.
Audric nous rejoint à ce moment et s'attèle à cette tâche.
La nécessité de faire un nouveau client web, un poil moins austère que l'actuel s'est rapidement faite sentir.
Au début de l'année nous rejoint donc Thomas qui entame l'écriture du nouveau client web avec angularjs.
Et nous voici au point où la première bêta de la réécriture est prête et la deuxième est dans les tuyaux.
Fonctionnalités
Cette nouvelle mouture est censée être isofonctionelle à l'ancienne, et bien sûr apporte certaines améliorations que voici.
Toutes les fonctionnalités sont disponibles dans le client web par défaut qui fait uniquement des appels à l'API Rest.
Il est donc possible d'utiliser n'importe quel client qui sait faire des requêtes HTTP.
La seule limitation dans cette première bêta (et pour la première version en fait) est qu'il est nécessaire d'avoir une session basée sur des cookies.
La gestion de l'authentification OAuth est planifiée pour la version 1.1.0.
Gestion des papiers
Dans un premier temps, un utilisateur connecté a accès à la page de gestion de ses papiers.
Il peut en créer de nouveaux, en supprimer, ou lancer l'édition d'un papier existant.
L'auteur d'un papier peut ajouter d'autres auteurs, qui verront à leur tour le papier apparaître dans leur liste, et pourront commencer à travailler dessus.
Un rôle de relecteur est aussi disponible, qui s'intégrera dans le workflow classique d'une soumission de papier scientifique que nous souhaitons intégrer dans \BlueLaTeX à moyen terme.
Un relecteur a un accès en lecture seule au papier, et pourra par la suite le commenter et l'annoter.
Édition de papier
La page d'édition d'un papier est composée d'un éditeur de texte, de la liste des fichiers et ressources du papier (fichiers TeX, BibTeX, images, …) et du rendu du papier compilé en pdf.
L'éditeur propose la coloration syntaxique et les fichier édités sont synchronisés en temps réel entre toutes les personnes connectées travaillant dessus.
Le support de SyncTeX permet de naviguer facilement entre l'éditeur et le pdf compilé, dans les deux sens.
Il est aussi possible de configurer la manière dont le document est compilé, notamment le compilateur à utiliser et l'intervalle entre deux compilations.
Les compilations se font en arrière plan, et ne sont pas lancées par l'auteur du papier.
Cette fonctionnalité est un essai, afin de voir si c'est plus simple et utilisable que l'ancien comportement où la compilation était lancée à l'initiative de l'utilisateur.
Il est possible de charger des images ou autres ressources associées à un papier, ces ressources ne sont pas synchronisées et n'ont pas vocation à être éditées dans le client web.
Si vous souhaitez créer un nouveau fichier synchronisé et éditable, il suffit de passer par l'interface du client web.
Comment qu'c'est qu'on essaye ?
Malheureusement, un bug de jeunesse nous empêche de faire une instance de test avec un utilisateur de test pour vous montrer cette bêta, j'espère pouvoir le corriger d'ici la prochaine.
En attendant, si vous souhaitez essayer chez vous, il vous suffit de télécharger l'archive de cette bêta, de la décompresser sur votre ordinateur, et de lancer la script dans le répertoire bin.
Afin que ça fonctionne correctement, il faut installer les dépendances nécessaires :
- couchdb en version 1.2.0 minimum,
- une JVM en version 7 minimum,
- il vous faudra un serveur smtp aussi pour valider l'inscription (FakeSMTP fait très bien l'affaire),
- et je crois que c'est tout…
Vous pouvez vous rendre sur http://localhost:8080/web/index.html et tester votre installation.
C'est une première bêta et toute la mécanique pour lancer proprement en démon n'est pas incluse mais devrait venir dans la prochaine.
Cette version n'est évidemment pas faite pour être mise en production mais vous pouvez tester à souhait.
Si vous vous sentez l'âme aventureuse et voulez tester en mode développement, il vous faudra 2 dépendances de plus :
- sbt pour compiler le tout,
- jsvc pour lancer le serveur de développement en démon.
Si vous avez toutes les dépendances installées, récupérer la dernière version et la lancer devrait être aussi simple que :
```sh
$ git clone git@github.com:gnieh/bluelatex.git
$ cd bluelatex
$ sbt
blueStart
blueStop
```
Si ce n'est pas aussi simple, un rapport de bug est le bienvenu pour améliorer tout ça.
Pour la prochaine bêta, et la version finale, nous travaillerons à améliorer la documentation de la configuration du serveur, pour le moment c'est assez peu (comprendre pas du tout) documenté.
Architecture globale
Sans rentrer dans les détails (loin de là), le serveur est conçu de façon modulaire, permettant d'ajouter ou retirer des fonctionnalités entières.
Par exemple le cœur du serveur, nécessaire pour pouvoir le faire tourner, contient la gestion des utilisateurs et des papiers.
La synchronisation est un module à part car le choix est donné entre notre implémentation du protocole ou l'implémentation originale de mobwrite.
Cette possibilité est donnée afin de pouvoir mieux s'intégrer dans une infrastructure existante qui utilisait l'implémentation originale.
Le module de compilation est complètement optionnel, car il est fort possible d'imaginer un client lourd qui permet aux différents auteurs de synchroniser leur travail, mais de compiler sur leur machine.
De nouveaux modules avec d'autre fonctionnalités sont dans les tuyaux pour les versions à venir, ce sera le moment de vérité afin de voir si notre architecture tient le coup !
\BlueLaTeX est en fait un ensemble de bundles OSGi qui devrait pouvoir tourner avec n'importe quelle implémentation de la spécification.
Nous utilisons par défaut felix, mais a priori vous devriez pouvoir vous en sortir avec equinox, knopflerfish ou autre.
Et la licence ?
Le tout vous est fourni sous licence Apache version 2.0
Pour finir
Toute idée, tout commentaire, toute critique constructive, tout rapport de bug, toute contribution, sera accueilli avec plaisir.
N'hésitez pas à ouvrir un ticket ou à nous rejoindre sur irc à #bluelatex@freenode.
Merci d'avoir pris le temps de me lire, et j'espère que ce projet vous plaira autant qu'il nous occupe, et que nous pourront l'améliorer grâce à vos retours.
# Excellent !
Posté par Victor . Évalué à 5. Dernière modification le 07 mai 2014 à 22:48.
C'est super comme initiative, il existe plusieurs solutions comme celle-ci mais la votre semble être la plus complète :)
Dès que la beta est utilisable, fais une dépêche !
Quelques commentaires sur tout et n'importe quoi :
Voilà pour le moment :)
Beau travail !
[^] # Re: Excellent !
Posté par Lucas . Évalué à 5.
Merci :)
On va stabiliser et simplifier la mise en place avant, mais j'y pense :)
Merci, c'est justement le genre de retour qui m'intéresse. J'avoue être partagé là, et je n'ai pas réussi à atteindre ce que je souhaitais pour le moment. Je pense que le retour à la compilation à l'initiative de l'utilisateur refera rapidement son retour, au moins par une option, voir en mode par défaut.
C'est pas super sympa de dévoiler mes plans de conquête du monde comme ça !
C'est exactement ce que nous avons en tête à moyen terme. La première version est un simple éditeur collaboratif, mais la prochaine devrait intégrer ce genre de concepts. Créer un papier pour une conf donnée avec ses templates, sa deadline, etc… Puis plein d'autres possibilités basées sur une utilisation dans le cadre de publications scientifiques devraient suivre. Notre todo list est chargée, yaka fokon !
# Installation
Posté par Gilbow . Évalué à 4.
Salut
Quelques petits points sur l'installation de la version binaire proposée:
- doit se lancer depuis le répertoire principal, avec quelque chose comme ./bin/blue-server-start
- classique, faut ouvrir le mail reçu, pour avoir l'url d'activation du compte.
- pour le template, un ticket est ouvert pour savoir quoi remplir (indiqué dans le ticket).
- pour l'instant, ça reste sur du localhost, mais ça se proxy bien avec un apache.
- texlive n'est pas mentionné, mais ça devait être implicite, c'est un paquet nécessaire à la compilation pour obtenir le pdf.
Personnellement je ne connais rien à LaTeX, mais j'ai obtenu un template.
Mes expérimentations se sont arrêtées là. Prochaine étape, le build à partir du dépôt ?
Bonne chance à \Blue
Gilbow
# Beau produit
Posté par Francky (site web personnel) . Évalué à 1.
Alors que je faisais l'écho de ce journal sur une place commune,
j'ai lâché une remarque que je vous laisse commenter si vous le souhaitez :
« La seule chose qui me gêne est l'emploi trop répété du mot "pro*et" ; (preuve) ; "produit" eut été mieux… »
[^] # Re: Beau produit
Posté par Lucas . Évalué à 1.
En effet et il le deviendra, mais en l'état, parler de produit serait un peu prématuré. Je ne pense pas projet comme un gros mot personnellement, pour le moment \BlueLaTeX a le projet de devenir un produit complet. Soyons honnête, il ne l'est pas encore, mais on s'y dirige.
[^] # Re: Beau produit
Posté par Francky (site web personnel) . Évalué à 2.
Concernant l'écho à faire, je crois savoir qu'il y a aussi une communauté active à avertir ici : [http://www.les-mathematiques.net/phorum/list.php?10] et là GGroups.
(Si ce n'est déjà fait)
[^] # Re: Beau produit
Posté par Lucas . Évalué à 3.
Pas encore fait, c'est une bêta. Avec les premiers retours et les premiers correctifs je pense que la prochaine milestone sera non loin de la RC. On commencera alors la communication du produit, pour l'instant je voulais juste présenter le projet :)
# Framabook
Posté par Christophe Masutti (site web personnel) . Évalué à 2.
Bravo !!
J'étais entré en contact avec vous au nom de Framasoft pour le projet Framabook il y a maintenant pas mal de temps et je vois que le projet est bien avancé !
Pour info, on a essayé d'installer FlyLaTeX (https://github.com/alabid/flylatex) mais on a eu des problèmes avec l'affichage du pdf.
Est-ce que vous utilisez la version de SharelaTeX ?
On serait bien preneurs d'une instance avec publication.li chez nous, pas seulement pour tester, mais si ca marche bien, pour carrément inviter nos auteur (ceux qui écrivent en LaTeX). En effet, dans notre chaîne, c'est toujours délicat de faire des corrections : avoir une plate forme où le code LaTeX est collaboratif pourra nous faciliter les choses :)
Encore bravo !
[^] # Re: Framabook
Posté par Lucas . Évalué à 2.
Je me souviens oui, on a pas mal été occupé depuis.
Je ne suis pas sûr de comprendre le sens de la question. Si on l'utilise pour comparer ? si notre code dépend du leur ?
La réponse à la première question est que oui j'ai testé, mais maintenant j'utilise \BlueLaTeX (eat your own food). Pour le deuxième cas, non. Notre viewer est pdf.js intégré par Thomas dans notre client, écrit par nous from scratch.
Pour une instance de \BlueLaTeX chez vous, je pense que le mieux c'est de reprendre contact par mail et que tu nous dises ce dont vous avez besoin exactement afin de voir ce qui est déjà ok ou non et donner une idée de la faisabilité en l'état.
J'espère pouvoir publier la M2 d'ici 2 semaines environ, qui devrait corriger pas mal de petites instabilités et surtout permettre de lancer le service plus proprement, mais c'est encore de la bêta, ne pas oublier :)
[^] # Re: Framabook
Posté par Christophe Masutti (site web personnel) . Évalué à 1.
RE-
Oui, ma question n'était pas claire, mais tu y as répondu :)
Du coup je pousse le bouchon : par rapport à ShareLaTeX (maintenant open), si j'ai bien compris vous pensez d'emblée en mode "chaîne de publication" : l'auteur soumet un papier.
Ce que j'ai du mal à voir, c'est comment vous pensez le système d'évaluation post-soumission ?
Pour les corrections, on peut penser que, par exemple, on mette le document en mode collaboratif pour que les correcteurs agissent directement dessus, mais pour les commentaires de fond?
Enfin, pour la compilation : sur le serveur, peut-on imaginer une suite complète type TexLive? Et si on veut par exemple utiliser BibLaTeX, ou beamer, c'est possible? :)
Truc à la con : on peut imaginer sa propre Classe de document (permettant d'avoir par exemple une maquette prédéfinie et ses dépendances) ? :)
Ha j'ai plein de questions !!
Merci :)
[^] # Re: Framabook
Posté par Lucas . Évalué à 5.
Toutes ces questions sont intéressantes, et nous avons déjà des plans pour, il faut que nous publions notre roadmap mise à jour, mais en résumé :
- un reviewer dans un contexte d'une publication scientifique ne peut pas modifier le papier, seulement le commenter. L'idée lorsque l'on passera le papier en mode revue est de figer la version du document (un tag) et de permettre aux personnes ayant les droits pour, de commenter le produit final, avant de repartir pour un incrément. Un état est ajouté au projet permettant certaines actions et en interdisant d'autre. Ceci est notre but, pas encore implémenté mais une partie de l'infrastructure pour y arriver est en place.
- nous appelons les outils installés sur le système pour compiler (voir commentaire plus haut), donc oui une suite complète texlive est envisageable vu que c'est ce que nous utilisons. D'ailleurs un fichier .bib est créé par défaut avec un nouveau document. Le processus de build du document (bibtex ou non ? index ou non ? …) est figé et rudimentaire mais pareil dans notre roadmap un système plus souple est pensé et prévu.
- pareil, pour les templates perso c'est dans les tuyaux.
Mais ne nous dispersons pas, tout ceci n'a aucun sens tant que les fonctionnalités de base ne sont pas stabilisées, nous préfèrons travailler en profondeur sur cette version pour avoir un truc qui marche et une vision claire, que de faire un truc tout en largeur qui tombe dès qu'on éternue à côté. N'en déplaise à certains, ceci est encore un projet en construction, pas un produit fini ;) Mais on y travaille avec nos ressources disponibles !
# Compilations alternatives
Posté par ziliss . Évalué à 3.
Et si on voulais utiliser du markdown à la place du latex (ou n'importe quel autre syntaxe), serait-ce difficile ou suffirait-il de remplacer l'outil de compilation ?
Serait-il difficile de compiler vers du HTML au lieu du PDF ?
(Je pense par exemple à un outil comme Pandoc)
[^] # Re: Compilations alternatives
Posté par Lucas . Évalué à 6.
Bon, encore un commentaire sur un truc que j'ai en tête :D Ça fait plaisir de voir que je suis pas le seul à avoir ces idées :)
J'ai un module à l'état de proto chez moi qui compile du markdown (c'est plutôt simple). A priori tout est là, il suffit de pouvoir choisir le type de document lors de la création, mais le protocole de synchronisation se moque pas mal de ce qu'il synchronise, donc rien à changer de ce côté.
La partie que je maîtrise le moins est le client, il faudrait pouvoir charger un viewer par type de document et pas un truc statique. J'en parlerai avec Thomas qui s'est occupé du client pour voir à quel point ça implique de modifier son code. Mais oui tout est possible, et l'archi modulaire a été pensée en ce sens.
# Je n’y connais rien…
Posté par yeKcim (site web personnel) . Évalué à 2.
J’adorerais utiliser et faire utiliser latex à mes collègues mais ce qui revient souvent comme argument contre son utilisation est que Word c’est génial pour le suivi de modification.
En parallèle, je constate qu’etherpad est très pratique pour le suivi de modifs justement avec des couleurs par contributeurs une timeline, des enregistrements de révisions…
Je me pose donc forcément la question con du mec qui n’y connaît rien. pourquoi ne pas ajouter à un etherpad (etherpad lite ?) des fonctionnalités de compilation. Avec des ajouts genre un choix coloration syntaxique / coloration contributeur. Ça décharge d’une partie du taf en plus…
[^] # Re: Je n’y connais rien…
Posté par Lucas . Évalué à 2.
Une des grosses différences est le protocole de synchronisation fondamentalement différent qui assure une convergence là où le protocole easysync peut diverger. Ce point est important pour nous surtout dans une vision décentralisée où finalement une instance \BlueLaTeX peut être un noeud dans un réseau d'instances interconnectées. Rien que la question de ce protocole de synchronisation change complètement la façon dont marche le client, le serveur, la gestion et l'affichage des différences, etc… Bref c'est plus la même chose du tout.
Il y a aussi beaucoup plus qu'un éditeur à ajouter, comme tous les concepts de rôles et workflow que nous souhaitions avoir.
Pour l'enregistrement des révisions, nous avons une autre approche différente basée sur l'intégration dans un logiciel de gestionnaire de versions, plutôt que de laisser cette compétence à l'algorithme de synchronisation (qui s'occupe de synchroniser, pas de versioner). Utiliser un gestionnaire de version dont c'est le métier permet d'hériter de tout un tas de fonctionnalités intéressantes comme des branches, des tag, etc… Et ces concepts sont dans notre viseur depuis le début.
Comme je l'ai précisé, \BlueLaTeX a pour vocation d'être plus qu'un simple éditeur \LaTeX, c'est d'être une plate-forme d'édition assez complète, l'approche me semble fondamentalement différente de celle d'etherpad. Je ne critique pas leur approche ou ce qui a été fait, je trouve etherpad très bien, mais ça ne correspond pas à ce que nous voulons avoir.
Ensuite à l'époque où nous avons commencé etherpad était aussi en scala, mais très monolithique, ce qui ne collait pas à notre vision. Maintenant etherpad c'est du node.js, techno que je ne maîtrise pas (ok c'est pas un argument, tout s'apprend :)).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.