Des solutions "Cloud" qui intègrent d'autres produits, ça existe. On peut parler de yunohost ou sandstorm. Mais elles n'offrent pas une expérience utilisateur cohérente et de pouvoir réutiliser des données entre applications. Pour moi, les forces de Cozy se trouvent justement là. Et, oui, ça demande souvent de réinventer la roue en moins abouti. Chaque application prise individuellement est moins bonne que la concurrence, mais c'est l'expérience globale qui compte.
Pour le lecteur de musique, on ne va pas remplacer les autres lecteurs. Mais il offre d'autres usages intéressants : tu peux vouloir faire écouter un morceau de musique quand tu es chez des amis, ou tu peux t'en servir pour écouter des podcasts que l'application konnectors aura récupéré automatiquement pour toi.
Cozy, comme toute plateforme, a besoin d'un écosystème assez riche pour montrer de quoi elle est capable. Mais je suis convaincu de son potentiel.
Je sens une grande frustration dans ton commentaire, mais j'ai du mal à pointer précisément vers quoi elle est tournée.
Pour la configuration minimum, ça reste une configuration minimum. Si tu veux effectivement avoir un Cozy rapide tout en ayant un usage poussé, il vaut mieux prendre une machine plus puissante.
la moitié des autres modules est ridicule (hastebin, term, irc!!!!, mstsc!!, map,…)
Ce sont des applications communautaires, développées par des gens externes à Cozy. Je trouve ça très positif que d'autres personnes contribuent ce qu'ils ont envie de voir dans Cozy.
Le Webmail: Je veux pas un Roundcube. Je veux l'équivalent de Gmail avec le serveur de mail fourni et GPG.
Même si on utilisait les 4 millions d'euros juste sur ça, on n'arriverait pas à faire ça. Le but est de faire un webmail avec lequel les gens sont à l'aise, mais qui bénéficie de l'intégration avec les autres applications Cozy.
L'appli Note: Je veux pas d'un notepad avec bullets et gras, je veux le petit frère d'Evernote.
Est-ce que certaines fonctionnalités en particulier te semblent importantes ?
L'appli Cal/Card: je veux pas un truc à la owncoud, je veux Google Calendar/Contacts… bon son petit frere. :P
Qu'est-ce qui te manque dans la version actuelle de Cozy ? La partie calendrier a des lacunes, mais contacts tient déjà bien la route.
L'appli Musique: Réellement? Si c'est ma collection privée, elle est dispo localement sur tous mes "devices".
Oui, dans ce cas, elle n'a pas beaucoup d'utilité pour toi. Mais je connais d'autres personnes qui s'en servent et en sont très contentes.
Le client IRC ne fait pas parti des applications installées par défaut sur une instance Cozy et n'a pas été développé par Cozy. Ceci dit, en temps qu'application communautaire, je trouve ça intéressant et j'espère que l'on va retrouver d'autres applications dans ce style.
Oui, ça aurait été bien d'avoir un tel document. Malheureusement, ça prend beaucoup de temps d'écrire ce genre de document, de communiquer dessus, écouter les retours, etc. Pour le cahier des charges, une grande partie est de l'existant que l'équipe connaît et ne prend donc pas le temps de documenter. Pour l'architecture, comme je propose quelque chose de nouveau, c'est une bonne occasion pour faire ce travail.
PS Bruno : ça fait plaisir de voir un projet qui écoute la/les communauté(s) et agis en conséquence ;) Cozy est très prometteur. (franchement j'attends de voir des gens de owncloud prendre la même patience et venir chercher les idées des gens)
Merci. On a la chance d'avoir une communauté constructive, alors on en profite !
À quand l'abandon de GitHub qui n'est pas un logiciel libre ?
Sans avancer de date, je peux dire que l'on regarde ce que fait gitlab.
2 Sur le site web de Cozy, où est la page valorisant l'adhésion de Cozy aux valeurs du logiciel libre ?
Il n'y a pas de page qui liste les valeurs de Cozy, ça apparaît sur plusieurs pages. Le premier des 5 mots cléfs pour décrire Cozy sur la page presse dit :
Ouverture : Cozy est disponible sous license open source et ses utilisateurs sont encouragés à modifier la plateforme et créer autout d'elle. Les développeurs peuvent étendre les fonctionnalités de Cozy en créant des applications et des connecteurs.
Échange de code entre les solutions libres de cloud, pas à ma connaissance. Il faut dire que ce ne sont pas les mêmes langages et technologies qui sont utilisées. Par contre, chacun utilise des bibliothèques libres développées ailleurs et en produit également. Il y a également des discussions entre Cozy Cloud, Owncloud et d'autres pour essayer d'avancer sur un standard pour partager des données entre ces solutions (exemple : un utilisateur d'owncloud pourrait vouloir partager un calendrier avec un autre utilisateur qui serait sur cozy).
Nous allons continuer à prendre en compte les auto-hébergés (dont je fais parti). Ça ne représente pas la majorité des utilisateurs mais ça reste un public important pour nous, notamment parce qu'ils sont souvent plus avancés techniquement et font plus de contributions.
La nouvelle architecture doit même rendre plus simple de s'installer un cozy chez soi.
C'est difficile de donner une date alors que je n'ai pas encore intégré tous les retours au document d'architecture. Probablement d'ici 6 mois à 1 an, selon la vitesse à laquelle on avance et si on parle de sortir une version alpha ou une version finale.
CouchDB parle en HTTP et a un mécanisme d'authentification (login+password pour se connecter à la base de données). Pour Cozy, les flux vers CouchDB passent par du code à nous pour vérifier l'authentification et les permissions (en mode reverse proxy).
Voici quelques caractéristiques de la réplication de CouchDB :
Elle se fait entre 2 bases de données CouchDB (ou autres instances qui parlent le protocole de réplication de CouchDB, pouchdb par exemple), sur le même serveur ou sur 2 serveurs différents.
Il n'y a pas de notion de primary/secondary entre ces 2 bases de données. Les 2 bases peuvent évoluer différemment (avec une notion de conflit quand un même document est modifié dans les 2 bases en même temps).
La réplication peut se faire dans un seul sens, ou dans les deux sens.
La réplication peut porter sur l'intégralité de la base de données, ou juste sur un sous-ensemble. Dans le second cas, on peut utiliser une fonction JavaScript qui va pour chaque document dire s'il doit être repliqué ou non. Par exemple, on peut vouloir répliquer que les documents qui ont le champ public avec une valeur true.
La réplication peut se faire en continu (on ouvre une socket entre les 2 bases de données et chaque modification est envoyée au fur et à mesure dans cette socket) ou en mode single-shot (une base de données dit à l'autre que lors de la dernière réplication, elle en était à telle révision et qu'elle aurait besoin des nouvelles modifications).
Du coup, ça permet de faire des choses assez sympas, comme avoir dans le navigateur une base de données locale, qui peut fonctionner en mode offline et se resynchroniser quand le réseau revient.
Effectivement, CouchDB sort des modèles classiques de base de données et il faut souvent un peu de temps avant de comprendre comment l'utiliser. Avec ses vues et requêtes, on arrive généralement à faire ce que l'on veut, mais c'est vrai que dans certains cas, l'absence de croisement de données manque (ça reste rare toutefois). C'est un niveau en-dessous des bases de données relationnelles, mais ça va, on vit avec.
Pour la recherche full-text, on n'a rien de comparable à ElasticSearch. On a essayé d'indexer les données de CouchDB via des moteurs externes (pas ElasticSearch, car il faut quand même que ça puisse tourner sur machines avec peu de RAM pour les auto-hébergés), mais ça n'a pas été très concluant.
Par contre, CouchDB a aussi des fonctionnalités très intéressantes (on serait passé à autre chose sinon). En particulier, la réplication est très puissante et on s'en sert beaucoup (pour le partage entre instance cozy, ou la synchronisation des contacts et calendriers entre le cozy et un smartphone).
Et, en production, c'est du solide. Pouvoir faire des backups à chaud juste en recopiant des fichiers est un gros plus.
En premier je trouve la démarche de présenter son architecture courageuse et sympa. Après je pense que c'est important d'écouter tous les conseils, mais de prendre des décisions selon sa vision.
Oui, ça résume bien ce que l'on essaye de faire. On ne peut évidement pas satisfaire tout le monde, mais des personnes en dehors de l'équipe ont sûrement des idées très pertinentes et il serait dommage de ne pas écouter leurs opinions.
Dans un groupe les personnes peuvent varier dans le temps mais (pour simplifier) l'ensemble des documents est propriété de ce groupe.
Exemple de groupe : une entreprise, un projet open-source, un groupe de travail, etc…
Non, il n'est pas prévu d'avoir de groupes sous cette forme là (une instance cozy partagée par plusieurs utilisateurs). Ça revient à faire un autre projet, avec d'autres préoccupations en termes d'expérience utilisateur, d'applications à mettre à disposition, etc. Et Owncloud/Nextcloud occupe déjà bien ce terrain.
Un autre notion de groupe que je ne vois pas apparaître est celle qui concerne les permissions (mais là c'est peut être en dehors des objectifs du document). Pourtant au niveau utilisateur, pouvoir donner accès à son album à toute la famille, dans le cas de l'instance groupe ci-dessus, pouvoir partager un document à tous les participants, etc…
Ça, par contre, avoir des groupes dans le cas du partage nous intéresse beaucoup.
Le partage dans la version actuelle de Cozy fonctionne avec la réplication entre instance CouchDB + du code pour gérer les droits. On souhaite reprendre le même mécanisme pour la nouvelle architecture. Mais ce n'est pas clair de comment faire ça proprement avec un groupe. On souhaite notamment avoir l'avis d'un expert CouchDB pour nous éclairer sur ce point (on va rencontrer Jan Lehnardt, un des créateurs de CouchDB, la semaine prochaine pour discuter de ça et d'autres points).
Oui, nous avons 2 thésards dans l'équipe qui travaillent sur les questions de partage et de calcul distribué. Ils suivent donc de près ce genre de sujets et m'ont confirmé que le chiffrement homomorphique n'est pas faisable actuellement pour cozy (en tout cas, pas si l'on veut des temps de réponse inférieure à la minute quand on fait une requête en base de données).
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).
Oui, c'est embêtant mais il y a beaucoup de boulot des 2 côtés qui seraient long et difficile à porter de l'autre. Donc, pour le moment, on va continuer avec les deux.
1 La réécriture en Go signifie-t-elle que tout le code backend actuel est jeté à la poubelle ?
Malheureusement, oui. Ceci dit, la grande majorité de notre code actuel est côté front et va pouvoir être gardé. Et pour le côté back, on a tiré des enseignements de la version actuelle qui vont bien nous aider pour la suite pour éviter de retomber dans les mêmes pièges (notamment, une bien meilleure connaissance de CouchDB).
2 Comment est-ce que seront écrites les applications de Cozy ?
Le but est d'avoir un maximum qui ne fonctionnent que côté client. La stack en Go va fournir un grand nombre de services communs aux applications pour ça.
Bien entendu, pour certaines applications, ça ne va pas être possible. Par exemple, The lounge, un client IRC, ne peut pas tourner côté client car il a besoin de se connecter à un serveur IRC (ce que les navigateurs web ne permettent pas). Dans ce cas, il est effectivement prévu de les faire tourner à côté et de les laisser discuter avec le core via l'API Rest.
3 Est-ce que le départ de Frank est lié à ce changement d'architecture ?
Les discussions ont commencé avant le départ de Frank et il a participé à celles-ci.
Une des raisons qui nous motive à changer d'architecture est le coût d'une instance Cozy. La version actuelle en nodejs est gourmande en RAM et ça coûte donc des sous pour héberger un Cozy (l'achat d'un RPi + électricité qui va avec, ou louer un serveur assez puissant chez un hébergeur, ou les sous de Cozy pour l'offre beta gratuite). On parle de quelques euros par mois (à multiplier par le nombre de personnes pour une famille si chacun veut son cozy). C'est un gros frein pour avoir beaucoup plus d'utilisateurs. Tout le monde est d'accord sur ce point.
Par contre, la suite à donner l'est moins. Frank défendait une approche où la majorité des personnes ont leur serveur (un RPi chez eux, ou un serveur loué à OVH, Gandi, etc.). Et dans cette approche, il est préférable de juste regrouper cozy-home, cozy-proxy et cozy-datasystem à l'intérieur d'un seul processus et d'optimiser sa consommation mémoire. Les gains sont faibles mais c'est relativement facile à mettre en place (en tout cas, bien plus facile que recoder le backend dans un autre langage).
À l'inverse, si la majorité des utilisateurs n'ont pas les compétences pour gérer leur serveur, ils vont se tourner vers des offres d'hébergement de cozy tierces. Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients. Dans ce cas là, il est possible d'aller beaucoup plus loin dans la réduction de la consommation de ressources (et donc faire baisser le prix d'une instance Cozy) en mutualisant les briques. Au lieu d'avoir un processus par utilisateur, on peut servir plusieurs utilisateurs avec ce même processus.
Le Concours d'Innovation Numérique a fait pencher la balance pour cette seconde option (et la levée de fonds auprès de la MAIF quelques mois plus tard a renforcé cela).
4 Comment est-ce que vous allez gérer la transition au sein de l'équipe de Cozy Cloud ?
Il est prévu que l'on soit 3 développeurs back :
un développeur recruté pour l'occasion
un développeur nodejs, qui a déjà regardé Go mais n'en a quasiment pas fait, et va donc se reconvertir
Mais nos développeurs JS ne vont pas chômer pour autant. Comme je l'expliquais plus haut, la majorité du code de Cozy est côté front. Actuellement, ils travaillent sur le client emails. Et il y a beaucoup d'autres choses qui les attendent ensuite.
5 Néanmoins, j'ai l'impression qu'il n'y a toujours pas de vision claire du modèle économique. Est-ce qu'il y a eu des évolutions à ce sujet ?
On souhaite que ce soient les entreprises qui nous payent, pas les particuliers. Ça peut-être des grands groupes comme EDF qui souhaitent expérimenter autour de Cozy ou qui veulent développer une application pour Cozy (même si tout le monde peut le faire, les grands groupes sont souvent rassurés si c'est nous qui le faisons). On souhaite également renforcer nos partenariats avec des hébergeurs comme Gandi et OVH. Et enfin, si MAIF et d'autres ensuite vont proposer des instances Cozy à leurs clients, nous seront forcément sur le chemin pour les accompagner.
6 Est-ce pour pouvoir s'intégrer dans un environnement comme celui de la MAIF qu'il a été envisagé de réécrire CozyCloud et d'en changer son architecture ?
On en revient à la question des coûts. La MAIF a des millions de sociétaires et si elle veut proposer une instance Cozy à chacun d'eux, c'est sûr que quelques euros par instance chaque mois, ça va être trop cher.
Est-ce que vous avez eu des discussions avec des architectes à cravate de chez eux à ce sujet ?
Non, il n'y a eu aucune discussion de ce type. Je pense que la MAIF nous fait entièrement confiance pour ça.
C'est effectivement cette solution que l'on envisage pour le passage de la version nodejs à celle en Go. Et pour le format de données, nous souhaitons avoir quelque chose de simple, documenté et qui repose autant que possible sur d'autres formats ouverts et interopérables. Ça permettra de déplacer son instance Cozy pour l'héberger ailleurs et pourra servir de passerelles vers d'autres solutions.
[^] # Re: Stop avec le RapberryPI
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 3.
Des solutions "Cloud" qui intègrent d'autres produits, ça existe. On peut parler de yunohost ou sandstorm. Mais elles n'offrent pas une expérience utilisateur cohérente et de pouvoir réutiliser des données entre applications. Pour moi, les forces de Cozy se trouvent justement là. Et, oui, ça demande souvent de réinventer la roue en moins abouti. Chaque application prise individuellement est moins bonne que la concurrence, mais c'est l'expérience globale qui compte.
Pour le lecteur de musique, on ne va pas remplacer les autres lecteurs. Mais il offre d'autres usages intéressants : tu peux vouloir faire écouter un morceau de musique quand tu es chez des amis, ou tu peux t'en servir pour écouter des podcasts que l'application konnectors aura récupéré automatiquement pour toi.
Cozy, comme toute plateforme, a besoin d'un écosystème assez riche pour montrer de quoi elle est capable. Mais je suis convaincu de son potentiel.
[^] # Re: Stop avec le RapberryPI
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 6.
Je sens une grande frustration dans ton commentaire, mais j'ai du mal à pointer précisément vers quoi elle est tournée.
Pour la configuration minimum, ça reste une configuration minimum. Si tu veux effectivement avoir un Cozy rapide tout en ayant un usage poussé, il vaut mieux prendre une machine plus puissante.
Ce sont des applications communautaires, développées par des gens externes à Cozy. Je trouve ça très positif que d'autres personnes contribuent ce qu'ils ont envie de voir dans Cozy.
Même si on utilisait les 4 millions d'euros juste sur ça, on n'arriverait pas à faire ça. Le but est de faire un webmail avec lequel les gens sont à l'aise, mais qui bénéficie de l'intégration avec les autres applications Cozy.
Est-ce que certaines fonctionnalités en particulier te semblent importantes ?
Qu'est-ce qui te manque dans la version actuelle de Cozy ? La partie calendrier a des lacunes, mais contacts tient déjà bien la route.
Oui, dans ce cas, elle n'a pas beaucoup d'utilité pour toi. Mais je connais d'autres personnes qui s'en servent et en sont très contentes.
Oui, et il sera présent au meetup ce soir.
[^] # Re: Stop avec le RapberryPI
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 7.
Qu'est-ce que tu appelles le "bundle" ?
Le client IRC ne fait pas parti des applications installées par défaut sur une instance Cozy et n'a pas été développé par Cozy. Ceci dit, en temps qu'application communautaire, je trouve ça intéressant et j'espère que l'on va retrouver d'autres applications dans ce style.
[^] # Re: Cahier des charges
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 3.
Oui, ça aurait été bien d'avoir un tel document. Malheureusement, ça prend beaucoup de temps d'écrire ce genre de document, de communiquer dessus, écouter les retours, etc. Pour le cahier des charges, une grande partie est de l'existant que l'équipe connaît et ne prend donc pas le temps de documenter. Pour l'architecture, comme je propose quelque chose de nouveau, c'est une bonne occasion pour faire ce travail.
[^] # Re: Mes 2 centimes
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. On a la chance d'avoir une communauté constructive, alors on en profite !
[^] # Re: Et les valeurs du logiciel libre ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 6.
Sans avancer de date, je peux dire que l'on regarde ce que fait gitlab.
Il n'y a pas de page qui liste les valeurs de Cozy, ça apparaît sur plusieurs pages. Le premier des 5 mots cléfs pour décrire Cozy sur la page presse dit :
[^] # Re: échange de code
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 5.
Échange de code entre les solutions libres de cloud, pas à ma connaissance. Il faut dire que ce ne sont pas les mêmes langages et technologies qui sont utilisées. Par contre, chacun utilise des bibliothèques libres développées ailleurs et en produit également. Il y a également des discussions entre Cozy Cloud, Owncloud et d'autres pour essayer d'avancer sur un standard pour partager des données entre ces solutions (exemple : un utilisateur d'owncloud pourrait vouloir partager un calendrier avec un autre utilisateur qui serait sur cozy).
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 7.
Nous allons continuer à prendre en compte les auto-hébergés (dont je fais parti). Ça ne représente pas la majorité des utilisateurs mais ça reste un public important pour nous, notamment parce qu'ils sont souvent plus avancés techniquement et font plus de contributions.
La nouvelle architecture doit même rendre plus simple de s'installer un cozy chez soi.
[^] # Re: Commits/pushs de code
Posté par Bruno Michel (site web personnel) . En réponse au journal LinuxFr.org : seconde quinzaine de juillet 2016 et mois d'août 2016. Évalué à 5.
Oui, pour les deux questions. Il faut avoir un karma strictement supérieur à la valeur par défaut pour modifier le wiki.
[^] # Re: ETA ?
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.
Quand ce sera prêt ;-)
C'est difficile de donner une date alors que je n'ai pas encore intégré tous les retours au document d'architecture. Probablement d'ici 6 mois à 1 an, selon la vitesse à laquelle on avance et si on parle de sortir une version alpha ou une version finale.
[^] # Re: Multi-utilisateur et stockage séparé
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 5.
Merci pour ce retour.
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
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.
C'est possible avec des extensions, mais je voulais parler au sein d'une application web (ce que sont les apps cozy).
[^] # Re: Mes 2 centimes
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 6.
Oui, ça serait sympa. Nous n'avons pas prévu de le faire nous-même mais si des contributeurs veulent faire ça, on peut les aider.
Oui, on va continuer à proposer une installation sans passer par Docker.
[^] # Re: Une vie sans jointure
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 9.
CouchDB parle en HTTP et a un mécanisme d'authentification (login+password pour se connecter à la base de données). Pour Cozy, les flux vers CouchDB passent par du code à nous pour vérifier l'authentification et les permissions (en mode reverse proxy).
[^] # Re: Une vie sans jointure
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 8.
Voici quelques caractéristiques de la réplication de CouchDB :
publicavec une valeurtrue.Du coup, ça permet de faire des choses assez sympas, comme avoir dans le navigateur une base de données locale, qui peut fonctionner en mode offline et se resynchroniser quand le réseau revient.
[^] # Re: Une vie sans jointure
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.
Effectivement, CouchDB sort des modèles classiques de base de données et il faut souvent un peu de temps avant de comprendre comment l'utiliser. Avec ses vues et requêtes, on arrive généralement à faire ce que l'on veut, mais c'est vrai que dans certains cas, l'absence de croisement de données manque (ça reste rare toutefois). C'est un niveau en-dessous des bases de données relationnelles, mais ça va, on vit avec.
Pour la recherche full-text, on n'a rien de comparable à ElasticSearch. On a essayé d'indexer les données de CouchDB via des moteurs externes (pas ElasticSearch, car il faut quand même que ça puisse tourner sur machines avec peu de RAM pour les auto-hébergés), mais ça n'a pas été très concluant.
Par contre, CouchDB a aussi des fonctionnalités très intéressantes (on serait passé à autre chose sinon). En particulier, la réplication est très puissante et on s'en sert beaucoup (pour le partage entre instance cozy, ou la synchronisation des contacts et calendriers entre le cozy et un smartphone).
Et, en production, c'est du solide. Pouvoir faire des backups à chaud juste en recopiant des fichiers est un gros plus.
[^] # Re: Notion de groupe ?
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.
Oui, ça résume bien ce que l'on essaye de faire. On ne peut évidement pas satisfaire tout le monde, mais des personnes en dehors de l'équipe ont sûrement des idées très pertinentes et il serait dommage de ne pas écouter leurs opinions.
Non, il n'est pas prévu d'avoir de groupes sous cette forme là (une instance cozy partagée par plusieurs utilisateurs). Ça revient à faire un autre projet, avec d'autres préoccupations en termes d'expérience utilisateur, d'applications à mettre à disposition, etc. Et Owncloud/Nextcloud occupe déjà bien ce terrain.
Ça, par contre, avoir des groupes dans le cas du partage nous intéresse beaucoup.
Le partage dans la version actuelle de Cozy fonctionne avec la réplication entre instance CouchDB + du code pour gérer les droits. On souhaite reprendre le même mécanisme pour la nouvelle architecture. Mais ce n'est pas clair de comment faire ça proprement avec un groupe. On souhaite notamment avoir l'avis d'un expert CouchDB pour nous éclairer sur ce point (on va rencontrer Jan Lehnardt, un des créateurs de CouchDB, la semaine prochaine pour discuter de ça et d'autres points).
[^] # Re: Le chiffrement
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 6.
Oui, nous avons 2 thésards dans l'équipe qui travaillent sur les questions de partage et de calcul distribué. Ils suivent donc de près ce genre de sujets et m'ont confirmé que le chiffrement homomorphique n'est pas faisable actuellement pour cozy (en tout cas, pas si l'on veut des temps de réponse inférieure à la minute quand on fait une requête en base de données).
De manière générale, dans l'ère post-snowden, il est difficile de se mettre à l'abri. Beaucoup de solutions vantent leur méthodes de discussions chiffrées, mais il est souvent possible de récupérer des meta-données malgré cela. Et il a été montré que les métadonnées sont généralement suffisantes pour une atteinte forte à la vie privée (cf http://mobile.lemonde.fr/pixels/article/2016/05/18/les-metadonnees-telephoniques-revelent-des-informations-tres-privees_4921532_4408996.html).
[^] # 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).
[^] # Re: Go!
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 9.
Avantages pour node :
Avantages pour go :
[^] # Re: konnectors et weboob
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 6.
Oui, c'est embêtant mais il y a beaucoup de boulot des 2 côtés qui seraient long et difficile à porter de l'autre. Donc, pour le moment, on va continuer avec les deux.
[^] # Re: Bon courage
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 suggestions. Je ne connais pas goshawdb, je vais regarder.
[^] # Re:Améliorer l’installation
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 5.
Oui, ensuite, quand on aura des paquets Debian propres, on va essayer de les faire adopter par Debian.
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 10.
Malheureusement, oui. Ceci dit, la grande majorité de notre code actuel est côté front et va pouvoir être gardé. Et pour le côté back, on a tiré des enseignements de la version actuelle qui vont bien nous aider pour la suite pour éviter de retomber dans les mêmes pièges (notamment, une bien meilleure connaissance de CouchDB).
Le but est d'avoir un maximum qui ne fonctionnent que côté client. La stack en Go va fournir un grand nombre de services communs aux applications pour ça.
Bien entendu, pour certaines applications, ça ne va pas être possible. Par exemple, The lounge, un client IRC, ne peut pas tourner côté client car il a besoin de se connecter à un serveur IRC (ce que les navigateurs web ne permettent pas). Dans ce cas, il est effectivement prévu de les faire tourner à côté et de les laisser discuter avec le core via l'API Rest.
Les discussions ont commencé avant le départ de Frank et il a participé à celles-ci.
Une des raisons qui nous motive à changer d'architecture est le coût d'une instance Cozy. La version actuelle en nodejs est gourmande en RAM et ça coûte donc des sous pour héberger un Cozy (l'achat d'un RPi + électricité qui va avec, ou louer un serveur assez puissant chez un hébergeur, ou les sous de Cozy pour l'offre beta gratuite). On parle de quelques euros par mois (à multiplier par le nombre de personnes pour une famille si chacun veut son cozy). C'est un gros frein pour avoir beaucoup plus d'utilisateurs. Tout le monde est d'accord sur ce point.
Par contre, la suite à donner l'est moins. Frank défendait une approche où la majorité des personnes ont leur serveur (un RPi chez eux, ou un serveur loué à OVH, Gandi, etc.). Et dans cette approche, il est préférable de juste regrouper cozy-home, cozy-proxy et cozy-datasystem à l'intérieur d'un seul processus et d'optimiser sa consommation mémoire. Les gains sont faibles mais c'est relativement facile à mettre en place (en tout cas, bien plus facile que recoder le backend dans un autre langage).
À l'inverse, si la majorité des utilisateurs n'ont pas les compétences pour gérer leur serveur, ils vont se tourner vers des offres d'hébergement de cozy tierces. Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients. Dans ce cas là, il est possible d'aller beaucoup plus loin dans la réduction de la consommation de ressources (et donc faire baisser le prix d'une instance Cozy) en mutualisant les briques. Au lieu d'avoir un processus par utilisateur, on peut servir plusieurs utilisateurs avec ce même processus.
Le Concours d'Innovation Numérique a fait pencher la balance pour cette seconde option (et la levée de fonds auprès de la MAIF quelques mois plus tard a renforcé cela).
Il est prévu que l'on soit 3 développeurs back :
Mais nos développeurs JS ne vont pas chômer pour autant. Comme je l'expliquais plus haut, la majorité du code de Cozy est côté front. Actuellement, ils travaillent sur le client emails. Et il y a beaucoup d'autres choses qui les attendent ensuite.
On souhaite que ce soient les entreprises qui nous payent, pas les particuliers. Ça peut-être des grands groupes comme EDF qui souhaitent expérimenter autour de Cozy ou qui veulent développer une application pour Cozy (même si tout le monde peut le faire, les grands groupes sont souvent rassurés si c'est nous qui le faisons). On souhaite également renforcer nos partenariats avec des hébergeurs comme Gandi et OVH. Et enfin, si MAIF et d'autres ensuite vont proposer des instances Cozy à leurs clients, nous seront forcément sur le chemin pour les accompagner.
On en revient à la question des coûts. La MAIF a des millions de sociétaires et si elle veut proposer une instance Cozy à chacun d'eux, c'est sûr que quelques euros par instance chaque mois, ça va être trop cher.
Non, il n'y a eu aucune discussion de ce type. Je pense que la MAIF nous fait entièrement confiance pour ça.
[^] # Re: Bon courage
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 7.
C'est effectivement cette solution que l'on envisage pour le passage de la version nodejs à celle en Go. Et pour le format de données, nous souhaitons avoir quelque chose de simple, documenté et qui repose autant que possible sur d'autres formats ouverts et interopérables. Ça permettra de déplacer son instance Cozy pour l'héberger ailleurs et pourra servir de passerelles vers d'autres solutions.