Pourquoi rester avec http ? On peut imaginer utiliser bittorrent pour diffuser les données. On peut même imaginer une sauvegarde par duplication chez les voisins, sécurisé par le cryptage symétrique, cela permet d'évacuer le problème de disponibilité des données si elles sont dupliquées et accessible ailleurs que sur un serveur perso.
Parce que http est bien plus souple. parce que tu as besoin de faire des requêtes et toutes sortes de transferts point à point, et de définir une API par dessus. parce que le support http en Go est plus avancé que celui pour bittorrent. probablement aussi parce que Brad est un expert dans ce domaine. Si ma réponse n'est pas satisfaisante, la ML camlistore@googlegroups.com est là pour ça. :-)
Pourquoi avoir choisi sha1, et pas un truc encore complétement sûr comme sha256 ?
Parce que sha1 suffit contre les collisions accidentelles. Ceci dit, ce n'est pas (complètement) codé en dur évidemment, et la possibilité d'utiliser d'autres hashes est bien sûr prévue.
Pour gérer les mises à jour, pourquoi ne peut jouer sur un numero de version basé sur une date, dans le fichier chapeau ?
Officiellement, on ne refuse aucune contribution dans d'autres langages (surtout pour les clients). Après, on fait presque tout en Go parce que c'est ce qu'on préfère et que c'est le plus adapté pour ce genre de projet (je ne vais pas me lancer dans un débat sur les langages), et tant qu'on y est on élimine peu à peu toutes les dépendances inutiles (surtout aux niveau des outils tiers et du système de build). Genre scripts perl, shell, makefile…
Petite correction sur l'histoire des "modifications mergées jusqu'à la dernière version", juste pour être sûr qu'il n'y ait pas de confusion.
Il n'y a pas de merging/fusion ou quoi que ce soit du genre. Tous les claims (modifications) restent stockés et distincts, et il n'y a pas à proprement parler d'objet qui représente la dernière version.
Simplement, quand on demande à voir l'état d'un permanode, l'indexeur va retourner le dernier claim pertinent en date pour chaque attribut (ou un sous ensemble, selon la requête). De même, lorsqu'on veut annuler une modification, il n'y a pas supression du claim concerné; un nouveau claim invalidant le claim concerné est créé.
Il s'en fiche puisque le soft est sous licence Apache. c'est même gagnant-gagnant d'une certaine manière; ce qui lui importe c'est que le soft soit libre, et en plus si jamais y'a des soucis de Copyright avec quelqu'un un jour, ce n'est pas lui qui aura à s'embêter avec les procès et les avocats, puisque c'est Google qui devra défendre le projet.
On refuse de compiler avec toute version en dessous de Go 1.1, certes. C'est une solution de facilité qui nous permet d'enlever certains hacks qui étaient nécessaires pour Go 1.0. Si quelqu'un en a vraiment besoin, ce n'est pas très difficile de remettre ces hacks et de désactiver le check pour Go > 1.1.
Après, toute personne faisant sèrieusement du Go vous encouragera clairement à installer Go 1.1. C'est officiellement la version stable, quoi qu'en disent les paquets des distros.
Etant fortement impliqué dans ce projet (et accessoirement pas chez Google), je peux vous confirmer que ce projet n'est pas du tout sous la tutelle de Google. Il se trouve juste que Brad en est le "leader", qu'il bosse dessus pendant ses week-ends, et que comme il est chez Google, tout travail qu'il produit est Copyright Google.
D'où la différence entre le fichier AUTHORS et CONTRIBUTORS, comme pour le projet Golang.
Mathieu
(qui avait un autre compte linuxfr mais qui ne le retrouve plus).
[^] # Re: Petites précisions
Posté par mpl . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. Évalué à 1.
Les blobs sont immuables.
[^] # Re: Petites précisions
Posté par mpl . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. Évalué à 3.
Parce que http est bien plus souple. parce que tu as besoin de faire des requêtes et toutes sortes de transferts point à point, et de définir une API par dessus. parce que le support http en Go est plus avancé que celui pour bittorrent. probablement aussi parce que Brad est un expert dans ce domaine. Si ma réponse n'est pas satisfaisante, la ML camlistore@googlegroups.com est là pour ça. :-)
Parce que sha1 suffit contre les collisions accidentelles. Ceci dit, ce n'est pas (complètement) codé en dur évidemment, et la possibilité d'utiliser d'autres hashes est bien sûr prévue.
Quelles mises à jour?
[^] # Re: Publicité mensongère
Posté par mpl . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. Évalué à 2.
Officiellement, on ne refuse aucune contribution dans d'autres langages (surtout pour les clients). Après, on fait presque tout en Go parce que c'est ce qu'on préfère et que c'est le plus adapté pour ce genre de projet (je ne vais pas me lancer dans un débat sur les langages), et tant qu'on y est on élimine peu à peu toutes les dépendances inutiles (surtout aux niveau des outils tiers et du système de build). Genre scripts perl, shell, makefile…
[^] # Re: Petites précisions
Posté par mpl . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. Évalué à 4.
Petite correction sur l'histoire des "modifications mergées jusqu'à la dernière version", juste pour être sûr qu'il n'y ait pas de confusion.
Il n'y a pas de merging/fusion ou quoi que ce soit du genre. Tous les claims (modifications) restent stockés et distincts, et il n'y a pas à proprement parler d'objet qui représente la dernière version.
Simplement, quand on demande à voir l'état d'un permanode, l'indexeur va retourner le dernier claim pertinent en date pour chaque attribut (ou un sous ensemble, selon la requête). De même, lorsqu'on veut annuler une modification, il n'y a pas supression du claim concerné; un nouveau claim invalidant le claim concerné est créé.
[^] # Re: 20%
Posté par mpl . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. Évalué à 4. Dernière modification le 02 juillet 2013 à 17:04.
Oui, c'est ce qu'il m'a dit.
Il s'en fiche puisque le soft est sous licence Apache. c'est même gagnant-gagnant d'une certaine manière; ce qui lui importe c'est que le soft soit libre, et en plus si jamais y'a des soucis de Copyright avec quelqu'un un jour, ce n'est pas lui qui aura à s'embêter avec les procès et les avocats, puisque c'est Google qui devra défendre le projet.
[^] # Re: merci !
Posté par mpl . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. Évalué à 4.
On refuse de compiler avec toute version en dessous de Go 1.1, certes. C'est une solution de facilité qui nous permet d'enlever certains hacks qui étaient nécessaires pour Go 1.0. Si quelqu'un en a vraiment besoin, ce n'est pas très difficile de remettre ces hacks et de désactiver le check pour Go > 1.1.
Après, toute personne faisant sèrieusement du Go vous encouragera clairement à installer Go 1.1. C'est officiellement la version stable, quoi qu'en disent les paquets des distros.
[^] # Re: 20%
Posté par mpl . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. Évalué à 4.
Etant fortement impliqué dans ce projet (et accessoirement pas chez Google), je peux vous confirmer que ce projet n'est pas du tout sous la tutelle de Google. Il se trouve juste que Brad en est le "leader", qu'il bosse dessus pendant ses week-ends, et que comme il est chez Google, tout travail qu'il produit est Copyright Google.
D'où la différence entre le fichier AUTHORS et CONTRIBUTORS, comme pour le projet Golang.
Mathieu
(qui avait un autre compte linuxfr mais qui ne le retrouve plus).