pour le reverse proxy, il est question de gérer TLS et d'avoir les droits sur les ports 80 et 443. Il serait AMHA intéressant de s'en servir aussi pour fournir les fichiers statiques du client web.
Oui, je pense que l'on va faire ça de manière optionnelle.
dans les stratégies de déploiement vous envisagez du multi datacenter ?
Pas dans cette version. On a déjà largement assez de boulot sans ça.
Il est vraiment nécessaire d'avoir des locks (distribués qui plus est) pour l'installation des applications ?
Actuellement, la version nodejs a des locks pour ce genre de chose (le risque est plus sur les mises à jour que les installations). Et avec plusieurs serveurs, ça va devenir encore plus compliqué à gérer. Donc, oui, je pense que l'on ne pourra pas se passer de locks.
Comment se passe le partage d'informations dans ce cas là ? Une recopie ?
Oui, on s'appuie sur la réplication de CouchDB pour le partage d'informations.
Est-ce qu'il ne serait pas intéressant d'avoir un système de label ? Chaque document possède un ou plusieurs labels. Les vues sont créé à partir de ses labels et il est possible de partager des document json sans difficulté
En pratique, cette approche est bien plus compliquée et pose des problèmes, notamment de performances. Ça veut dire que lorsqu'un document est ajouté/modifié/supprimé, il faut mettre à jour toutes les vues de tous les utilisateurs, ce qui est assez gourmand en ressources pour CouchDB.
On va discuter avec Jan Lehnardt (un des créateurs de CouchDB) la semaine prochaine, notamment pour s'assurer que ce que l'on veut faire est bien dans l'esprit de CouchDB et ne nous posera pas de problèmes de performances/scalabilité plus tard.
je n'ai pas vu (ou pas compris) le modèle d'exécution des application tierce, notamment pour tout ce qui est gestion des droits
Oui, ça reste à détailler. Je ne voulais pas retarder plus longtemps la publication du document d'architecture et l'appel à commentaires associés pour avoir des retours avant de commencer à coder. Mais c'est vrai que certaines parties sont encore loin d'être claires (y compris pour moi).
[^] # Re: Petits retours
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 4.
Merci pour ces retours !
Oui, je pense que l'on va faire ça de manière optionnelle.
Pas dans cette version. On a déjà largement assez de boulot sans ça.
Actuellement, la version nodejs a des locks pour ce genre de chose (le risque est plus sur les mises à jour que les installations). Et avec plusieurs serveurs, ça va devenir encore plus compliqué à gérer. Donc, oui, je pense que l'on ne pourra pas se passer de locks.
Oui, on s'appuie sur la réplication de CouchDB pour le partage d'informations.
En pratique, cette approche est bien plus compliquée et pose des problèmes, notamment de performances. Ça veut dire que lorsqu'un document est ajouté/modifié/supprimé, il faut mettre à jour toutes les vues de tous les utilisateurs, ce qui est assez gourmand en ressources pour CouchDB.
On va discuter avec Jan Lehnardt (un des créateurs de CouchDB) la semaine prochaine, notamment pour s'assurer que ce que l'on veut faire est bien dans l'esprit de CouchDB et ne nous posera pas de problèmes de performances/scalabilité plus tard.
Oui, ça reste à détailler. Je ne voulais pas retarder plus longtemps la publication du document d'architecture et l'appel à commentaires associés pour avoir des retours avant de commencer à coder. Mais c'est vrai que certaines parties sont encore loin d'être claires (y compris pour moi).