bon bon, on n'est pas d'accord. Je ne voulais froisser personne ici, c'est seulement mon feeling au sujet de ces outils. probablement mal exprimé.
OPA j'ai testé, il y à longtemps, je n'y suis pas revenu. Est ce un avantage ou un inconvénient pour l'adoption de votre proposition. J'émet un doute, qu'on me prouve le contraire je change ma suite d'outils.
Même doutes au sujet de docker, mais je n'ai pas suffisament testé.
Pour la question des bindings, il y à node gyp, et plus particulièrement node pre gyp. Ce que JS ne peut faire tout seul correctement, on le délègue à un language approprié, mais la philosophie reste la même derrière, fournir un service multi plateforme de qualité.
Cela prends du temps, mais j'y crois car je le vois.
Simplicité de déploiement et d'usage, c'est surtout une question de savoir faire des techniciens qui sont derriere.
Mais en réduisant le nombre d'outils (ie : un seul binaire pour tous, au lieu de nn binaires), on réduit sa surface de développement, de test, de controle, d'intéractions et autre comportements inattendus.
Je crois.
De plus j'ai le sentiment qu'en nodejs, tout est plus petit, plus simple à manipuler, déployer.
Ok ce n'est qu'un sentiment.
Au sujet de bitorrent, il faut faire la part des choses nous avons dht, et bittorrent. Il est avisé de prendre avantage de la dht pour trouver des peers (enfin, je voudrait bien voir tourner kadnode irl et obsrver ce que cela donne : ), et il y à bt, pour échanger des données publique. Lorsqu'il s'agit de partager un document privé entre deux peers, on peut demander si bt est vraiment la manière la plus efficiente.
M'enfin bref, on devrait surtout se focaliser sur ce que l'on peut partager, par exemple ces schémas d'api. L'utilisateur ne devrait pas souffrir d'avoir choist tel ou tel backend pour gérer ces services et pouvoir switcher de l'un à l'autre facilement. Voir plus simplement décorellés toutes ces dépedances pour donner la possibilité à d'autres d'intégrer ces services, ou de s'y intégrer facilement.
Ces querelles de techniciens ne nous mènent pas bien loin comme on le constate. Essayons plutot trouver des points de convergences non ?
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par maboiteaspam . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à -1.
bon bon, on n'est pas d'accord. Je ne voulais froisser personne ici, c'est seulement mon feeling au sujet de ces outils. probablement mal exprimé.
OPA j'ai testé, il y à longtemps, je n'y suis pas revenu. Est ce un avantage ou un inconvénient pour l'adoption de votre proposition. J'émet un doute, qu'on me prouve le contraire je change ma suite d'outils.
Même doutes au sujet de docker, mais je n'ai pas suffisament testé.
Pour la question des bindings, il y à node gyp, et plus particulièrement node pre gyp. Ce que JS ne peut faire tout seul correctement, on le délègue à un language approprié, mais la philosophie reste la même derrière, fournir un service multi plateforme de qualité.
Cela prends du temps, mais j'y crois car je le vois.
Simplicité de déploiement et d'usage, c'est surtout une question de savoir faire des techniciens qui sont derriere.
Mais en réduisant le nombre d'outils (ie : un seul binaire pour tous, au lieu de nn binaires), on réduit sa surface de développement, de test, de controle, d'intéractions et autre comportements inattendus.
Je crois.
De plus j'ai le sentiment qu'en nodejs, tout est plus petit, plus simple à manipuler, déployer.
Ok ce n'est qu'un sentiment.
Au sujet de bitorrent, il faut faire la part des choses nous avons dht, et bittorrent. Il est avisé de prendre avantage de la dht pour trouver des peers (enfin, je voudrait bien voir tourner kadnode irl et obsrver ce que cela donne : ), et il y à bt, pour échanger des données publique. Lorsqu'il s'agit de partager un document privé entre deux peers, on peut demander si bt est vraiment la manière la plus efficiente.
M'enfin bref, on devrait surtout se focaliser sur ce que l'on peut partager, par exemple ces schémas d'api. L'utilisateur ne devrait pas souffrir d'avoir choist tel ou tel backend pour gérer ces services et pouvoir switcher de l'un à l'autre facilement. Voir plus simplement décorellés toutes ces dépedances pour donner la possibilité à d'autres d'intégrer ces services, ou de s'y intégrer facilement.
Ces querelles de techniciens ne nous mènent pas bien loin comme on le constate. Essayons plutot trouver des points de convergences non ?