Bruno Michel a écrit 3285 commentaires

Perso je trouve que CouchDB est un très bon SGDB NoSQL par contre s'en servir pour stocker les fichiers est une gageure comme échangé dans cette discussion.

Je suis d'accord. D'ailleurs, j'ai aussi donné ma position dans cette même discussion ;-)

Pour être honnête, quand nous avons vu cet article de NI, nous avons été affligés. Il était rédigé d'une façon qui ne correspondait pas à ce que l'on fait chez Cozy. Il a été réécrit en partie depuis, mais la dépêche sur LinuxFr.org reste meilleure à mon humble avis.

Pour répondre sur le fond, nous sommes chez Cozy très attachés aux questions de vie privée et de contrôle des données personnelles. Il est totalement hors de question que des grandes entreprises puissent piller les données via Cozy. Le système de permissions pour accéder aux données ne couvre qu'une partie du problème. Nous souhaitons également mettre en place des outils pour que l'utilisateur sache si des données remontent vers l'entreprise et, si oui, quelles données.

On peut imaginer qu'une application MAIF puisse accéder à des données personnelles, disons des données bancaires, pour me proposer un contrat d'assurance quand j'achète une nouvelle voiture. La manière dont on voit les choses, c'est que l'utilisateur (moi) a d'abord fait le choix d'installer l'application MAIF et lui a donné les permissions d'accéder aux données bancaires (c'est dans la même veine que le contrôle des autorisations sur android et iOS). Ensuite, l'application MAIF tourne sur mon serveur et ne peut pas envoyer de données aux système d'information de la MAIF sans mon consentement. Elle pourrait utiliser une notification Cozy pour m'avertir que la MAIF pourrait assurer ma voiture (si l'appli spamme trop, je ne me priverais pas de lui couper l'accès aux notifications). Si je clique sur la notification, j'accède à l'application MAIF sur mon Cozy. À ce moment là, la MAIF n'a toujours eu aucune idée de ce qui se passait. Et si finalement, je suis intéressé, je peux contacter la MAIF, probablement via un email pré-rédigé mais dont je vérifie le contenu avant de l'envoyer. Ainsi, la MAIF a pu me proposer un contrat d'assurance auto de manière pertinente, mais n'a jamais eu accès à mes données personnelles.

C'est une bonne idée, Kinto et CouchDB sont assez proches.

Nous sommes en contact avec Alexis Métaireau, ancien de Mozilla et développeur de Kinto. A priori, on ne va pas refondre Cozy pour utiliser Kinto. Ça serait beaucoup de boulot et CouchDB/PouchDB nous permettent plus de choses actuellement. Par contre, il y a de bonnes idées à prendre chez Kinto et il y a sûrement des choses à faire en collaboration.

Ça veut dire que l’appli android embarque un serveur couchdb ?

On utilise PouchDB sur android.

Même avec cette levée de fonds, nos moyens restent limités. Nous préférons nous concentrer sur une utilisation personnelle. Owncloud est probablement plus adapté pour un usage en entreprise. Il n'est donc pas prévu d'avoir de gestion multi-utilisateurs à court terme.

Je vais quand même nuancer : nous avons toujours un cas qui nous embête un peu, celui d'une famille. Pour auto-héberger un cozy pour chaque membre de la famille, c'est effectivement trop compliqué pour le moment et nous souhaiterions améliorer ça.

Oui, ça va être ouvert pour d'autres TLD.

Je n'ai pas trop suivi cette partie, mais dans l'idée, ça s'adresse plutôt à nos partenaires hébergeurs qui vont proposer directement à leurs clients (sans rapport avec la MAIF). Ils pourraient proposer un pack, avec un nom de domaine, un compte email et une instance Cozy déjà configurée. Cette instance Cozy servirait de webmail, de gestionnaire de contacts et calendriers, d'espace de synchronisation de fichiers, etc.

Et bien sûr, si ça ne suffit, il reste toujours la possibilité de prendre son nom de domaine d'un côté, un serveur de l'autre (avec une image Cozy de préférence pour ne pas s'embêter avec l'install et les sauvegardes) et le tour est joué.

D’après ce que j’avais lu, couchdb est vraiment plus lent par rapport à MongoDB.

Oui, mais il y a de bonnes raisons à ça. MongoDB privilégie la vitesse à quasiment tout le reste. Du coup, ça fait joli dans les benchmarks mais, dans la vraie vie, on se retrouve avec des données égarées. Je parle d'expérience, mais voici quelques articles vite fait sur le sujet :

• https://aphyr.com/posts/284-call-me-maybe-mongodb
• https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
• https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827

Dans certains cas, c'est acceptable. Par exemple, quand on stocke de grandes quantités de données sur le comportement des utilisateurs pour pouvoir en tirer des informations statistiques a posteriori, ce n'est pas très grave s'il manque quelques enregistrements par ci par là. Si on veut garder la position d'un utilisateur en permanence, pareil, on peut se permettre de rater quelques positions, ça ne fera pas une grosse différence. Et la vitesse de MongoDB est appréciable pour ces cas d'usage.

Par contre, perdre des données personnelles dans un Cozy, non, ce n'est pas acceptable. MongoDB ne sera jamais la base de données de Cozy.

L’avantage qu’il procure en terme de réplication / distribution ne me paraît pas très pertinent dans le cas de cozycloud (du moins, pas tant qu’il restera mono-utilisateur).

Pourtant, la réplication nous est plus utile que les performances brutes. Nous l'utilisons pour l'application android pour synchroniser les contacts, calendriers et photos entre le mobile et l'instance Cozy. Nous avons également 2 personnes en thèse chez nous qui travaille sur le partage et la réplication de CouchDB est mise à profit pour partager de événements d'un calendrier entre utilisateurs (et bientôt plein d'autres choses). On aimerait également utiliser ça pour avoir des web apps qui fonctionnent en mode offline.

Et me virer CouchDB !!

Qu'est-ce qui te dérange dans CouchDB ?

Oui, Cozy Cloud demande 1 à 2 Go de RAM pour tourner confortablement et c'est trop. Nous en sommes conscients. D'ailleurs, que ce soit notre partenariat avec Gandi ou cette levée de fonds avec la MAIF, nous nous retrouvons dans une position où il devrait y avoir des millions d'instances Cozy déployées dans un futur pas si éloigné que ça. Et une telle consommation mémoire est un frein important pour cela. Nous comptons donc bien y remédier et les quelques millions d'euros vont aider pour ça !

Par contre y a t il un lien direct dans l'application file pour partager un fichier/dossier avec quelqu'un ?

Oui, on peut partager facilement depuis l'application files.

Est ce qu'on a un accès direct via webdav au système de fichier ?

Non, actuellement les données sont stockées dans CouchDB. On envisage d'avoir un système de stockage modulable où l'administrateur peut choisir où sont stockés les données : dans CouchDB, sur le file system local ou dans un truc comme Open Stack. Pour les auto-hébergés, avoir les fichiers sur le files system serait mieux. Pour les hébergeurs avec beaucoup d'instances Cozy, avoir les fichiers dans un truc comme Open Stack serait plus facile à gérer. Mais bon, nos moyens sont limités et ce n'est pas là que les efforts vont porter dans les prochains mois. On a beaucoup de sujets sur le feu, il faut choisir nos combats.

D'autre part, les fichiers peuvent être répliqués sur un ordinateur personnel sous Linux via le tout nouveau client : https://linuxfr.org/news/synchronisez-vos-fichiers-avec-cozy-desktop.

Est ce que le webmail fonctionne avec free ?

Il y a un gros travail de refonte en cours du webmail. Il fonctionnait avec free et refonctionnera bientôt. C'est juste que l'on avait beaucoup de petits bugs, un peu de dette technique, un react assez vieux, etc. Et on prend le temps de refaire ça bien pour avoir un webmail que les gens puissent vraiment utiliser au quotidien sans pester sur beaucoup de petits détails.

Est ce que les protocoles CardDav et CalDav (plugin sync) fonctionnent bien ?

À ma connaissance, oui.

Ou alors peut-on partager avec l'utilisateur d'une autre instance Cozy (local voire même indépendant)?

Pas encore. Chez Cozy Cloud, nous avons 2 personnes en thèse (Paul et Julien) et ils travaillent sur le partage de cozy à cozy. Actuellement, on peut "partager" un événement d'un calendrier entre plusieurs instances cozy. Là, ils travaillent sur le partage d'un calendrier complet. Et l'étape suivante devrait être le partage de fichiers et répertoires.

C'est une très bonne idée et quelque chose que j'aimerais aussi avoir. Par contre, nos moyens sont limités : je suis le seul développeur sur l'application cozy-desktop et la priorité est pour le moment de stabiliser la version linux et le portage sous OSX. Un tel projet ne rentre pas dans notre roadmap pour les 6 mois qui viennent.

Si des contributeurs externes sont intéressés pour réaliser ce projet, ça serait super et j'aiderais, bien sûr. Une synchro intégrée au navigateur de fichiers serait vraiment cool !

en lisant la dépêche, j'ai l'impression que votre client synchronise l'ensemble du cloud. Comment on fait si on a des dizaines de GB pour synchroniser sur un périphérique avec peu d'espace de stockage?!

Pour cette première version, oui, on synchronise tous les fichiers. Mais ça ne va pas durer, on a prévu de pouvoir synchroniser juste certains répertoires. On fera ça plus ou moins vite selon les retours des utilisateurs. Et je pense que c'est quelque chose que l'on va beaucoup nous demander, donc ça devrait arriver assez rapidement.

Merci pour le retour. En fait, le texte est déjà corrigé, c'est juste que la capture d'écran a été prise juste avant.

En ce qui me concerne, y a-t-il une alternative qui me permette :
- synchronisation de fichiers entre plusieurs hôtes Linux (distros différentes) / terminaux Android
- synchronisation d'agendas multiples et contacts entre Thunderbird / terminaux android (avec les applis natives de gestion de contacts et calendriers)
- accès via web à tout cela, en cas d'urgence / indisponibilité d'un terminal configuré ?

C'est peut-être le moment de tester Cozy Cloud.

Nous avons déjà une application android pour synchroniser les calendriers, contacts et fichiers. L'interface web pour consulter tout ça existe également. Et pour la synchro de fichiers depuis un hôte Linux, j'ai passé pas mal de temps ces derniers mois pour coder ça et on est en train de publier la version beta.

Je me suis mal exprimé. Non, l'entreprise ne va pas accéder directement aux données. Elle va juste pouvoir les utiliser dans le cadre du Cozy.

Avec un exemple, ce sera plus clair. EDF n'a pas accès aux données de Nest. Par contre, l'utilisateur est tout à fait légitime pour avoir les données de Nest sur son Cozy et il peut aussi faire tourner sur son Cozy une application EDF. Cette application pourra accéder ainsi accéder aux données de Nest pour, disons, proposer un contrat plus adapté à l'utilisateur. Les données vont rester sur le cozy, sous le contrôle de l'utilisateur, sur son serveur, pas celui d'EDF. Elles ne vont jamais remonter jusqu'à EDF.

Le principe de Cozy cloud est de pouvoir reprendre le contrôle de ses données et de pouvoir ainsi les faire interagir.

Cozycloud est un bon exemple, est-ce que quelqu'un connaissant le type de vente faite par Cozy pourrait nous dire ce qu'ils vendent ? Des contrats de maintenance ? Du support ? Du développement de fonctionnalités ?

La réponse est sur https://cozy.io/fr/about/.

Globalement, nous vivons actuellement en partie des sous de la dernière levée de fonds et, pour le reste, des revenus via des contrats avec des grosses entreprises. Pour la suite, nous pensons surtout vendre des choses à des entreprises (grands comptes et hébergeurs), pas directement à nos utilisateurs. Pour les hébergeurs, c'est du support + des outils spécialisés pour héberger de nombreuses instances cozy. Pour les grands comptes, c'est une réflexion et du prototype d'apps cozy pour les services innovation qui veulent utiliser les données d'utilisateurs auxquelles ils n'auraient pas accès normalement. Mais on pourrait aussi imaginer des services pour les utilisateurs finaux (des boitiers cozy ou un service de sauvergarde chiffrée pour les auto-hébergés par exemple).

Bug corrigé avec https://github.com/linuxfrorg/linuxfr.org/commit/f2b3a79fbfa3a54ff7a92663e46b0562b8e51e6e

Cf https://github.com/linuxfrorg/linuxfr.org/commit/f2a42c85effca26b06a957281b5efc5459cdc602

En pratique, les études comme https://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns montrent qu'il y a trop de frameworks, trop de versions de frameworks et trop peu de sites qui utilisent les CDN pour que ça marche vraiment.

et bien, pourquoi ne fais tu pas du ruby ou de l'elixir alors ?

Parce que ce n'est pas moi qui ait choisi ;-)

Il y a plusieurs raisons en fait :

• Je travaille en équipe et je ne peux pas choisir ça tout seul dans mon coin. D'autres personnes vont intervenir et elles ne connaissent pas Ruby et encore moins Elixir.

• Le projet était déjà commencé quand je suis arrivé et je l'ai repris. C'est compliqué de changer de langage en cours de route.

• Le développement de Cozy-desktop est pas mal aidé par une bibliothèque, PouchDB. Ce n'est pas facile de lui trouver un équivalent en Ruby.

Oui tu devrais essayer comme je t'ai montré ici http://linuxfr.org/nodes/108933/comments/1656878

Je regarde mais ça n'a pas l'air de trop m'aider pour la gestion des erreurs. Je me retrouve toujours avec du code spaghetti.

Bah, moi aussi, je l'avais oublié !

Mesurer l'I/O c'est principalement mesurer l'OS, ça a très peu d’intérêt pour un bench qui veut évaluer un langage.

Et pourtant, il y a de très gros écarts sur un benchmark comme celui de Tech Empower.

https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=query -> sur cet exemple, le C++ est loin derrière Java et Dart (!!?). Pourtant, il devrait être plus près de l'OS en termes d'appels systèmes et avec la gestion manuelle de la mémoire, il devrait être bien devant selon tes dires. Comme quoi, ce n'est pas si simple.

Tu as déja fait du C++ une fois dans ta vie pour sortir des énormités pareilles ? Depuis quand un programme C++ a besoin de bindings pour utiliser du C ?

Oui, j'ai déjà fait du C++ et non, le C++ n'a pas besoin de bindings pour faire du C. Je ne voulais pas parler uniquement du C++ mais de tous les langages qui utilisent des bibliothèques en C alors qu'ils pourraient faire sans avec le langage en question. Pour certains langages, ça passe par des bindings, pas pour le C++, et j'ai tout mis ensemble sous l’appellation de bindings ves le C.

Ceci dit, mon point reste valide. Les règles du benchmark m'ont l'air floues pour savoir quand on peut utiliser une bibliothèque en C dans un langage autre que le C.

Même si j'aurais plutôt dit qu'avec de grands pouvoirs viennent de grandes responsabilitées !

Je n'ai vraiment pas l'impression d'avoir de grands pouvoirs avec Node.js, en tout cas, beaucoup moins que dans d'autres langages comme Ruby ou Elixir.

Ceci dit avec async j'ai l'habitude d'avoir un callback de fin pour rattraper l'exception.

Il y a un callback de fin dans mon exemple. Mais le callback de fin d'async n'attrape pas les exceptions, juste les erreurs passés en premier paramètre d'un callback. Et avec les streams, ça se combine très mal.

Pour préciser, j'avais parlé d'exception 'uncaught', car c'est ce qui arrive avec async@1.5.2. Là, avec async@2.0.0-rc4, le comportement a changé et on passe dans le on('error'). Oui, node.js est vraiment un endroit très piégé !

Oui, c'est dans le source.on('error') qu'il faut afficher err.stack, mais ça me donne juste :

Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native)

La stack trace de node 6 est juste pourrie.