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 :)).
[^] # Re: Je n’y connais rien...
Posté par Lucas . En réponse au journal \BlueLaTeX reloaded sort en bêta !. É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 :)).