Dans l'idéal, il faut laisser la liberté à l'utilisateur de choisir où il souhaite entreposer ses données privées et publiques.
On doit donc disposer d'un protocole ouvert qui permet d'interconnecter les entrepôts de données facilement entre eux.
Ceci permet à un autre fournisseur d'infrastructure de se connecter au réseau.
L'utilisateur paranoiaqueprudent par exemple pourrait choisir de stocker ses données privées chez lui et ses données publiques sur un serveur mutualisé.
Un autre utilisateur pourrait choisir de stocker l'ensemble de ses données chez un fournisseur d'infra.
Il vaut mieux payer monnaie comptante pour un service mutualisé (modèle économique) que d'avoir l'illusion de services gratuits qui on un coût caché (publicité, ReCaptcha, ...) et qui enferment vos données. Le potentiel du social, celui qui fait que la valeur totale des données collectées est plus riche que la somme des valeurs individuelles (rappelez vous la pertinence des tags proposés dans del.icio.us qui s'appuie sur l'effort de d'étiquetage de chacun). Ce potentiel là revient dans les mains du libre avec une véritable architecture distribué et avec des données libres si on souhaite les partager.
C'est le retour en force du libre sur les données.
Pour en revenir à notre utilisateur, comme il remet son destin entre les mains d'un tiers, le protocole et l'architecture doivent s'assurer que les données privées sont encryptées et fiables autant que possible. Le fait que l'infrastructure logicielle sur laquelle il s'appuie est une garantie supplémentaire de sécurité, même si elle n'est jamais totale.
Cette infrastructure et ce protocole doivent pouvoir aussi assurer un certain niveau de réplication des données pour permettre de pointer sur un noeud différent en cas de défaillance du noeud principal.
Tout ceci doit être contrôlable et configurable
L'étape ultime est la distribution des traitements.
Imaginons avec l'exemple de delicious que , un peu à la manière dont fonctionne le moteur de recherche Yacy (yacy.org) que lorsque je souhaite apposer un tag que non seulement la base de données qui associe les tags au urls soit répartie mais que les requêtes de suggestions de tags soient elles aussi séparées et distribuées pour être assemblée avant de me les servir.
Si je choisis d'héberger mon propre noeud, je peux optimiser en local et mettre à disposition les ressources à la puissance commune.
Si je suis un candide qui découvre un service ou que je suis nomade, un simple navigateur me suffit.
La puissance de calcul répartie à l'échelle du Web, finirait d'achever le "Web 2.0", celui qui fait que des organismes centralisent et enferment vos données dans un web conçu à la base pour être ouvert et distribué
I have a dream
Bon, je retourne me reprendre un peu de moquette.
Plus sérieusement, est-ce que quelqu'un qui s'est déjà penché dessus pourrait détailler un peu ce protocole "Open Collaboration Services" et les infras derrière .
S'agit-t'il d'une API REST, y at'il du XMPP ? Y'a t'il des hastables distribuées derrière, ...
[^] # Re: service ?
Posté par El Titi . En réponse à la dépêche Sortie d'ownCloud 1.0. Évalué à 8.
On doit donc disposer d'un protocole ouvert qui permet d'interconnecter les entrepôts de données facilement entre eux.
Ceci permet à un autre fournisseur d'infrastructure de se connecter au réseau.
L'utilisateur paranoiaqueprudent par exemple pourrait choisir de stocker ses données privées chez lui et ses données publiques sur un serveur mutualisé.
Un autre utilisateur pourrait choisir de stocker l'ensemble de ses données chez un fournisseur d'infra.
Il vaut mieux payer monnaie comptante pour un service mutualisé (modèle économique) que d'avoir l'illusion de services gratuits qui on un coût caché (publicité, ReCaptcha, ...) et qui enferment vos données. Le potentiel du social, celui qui fait que la valeur totale des données collectées est plus riche que la somme des valeurs individuelles (rappelez vous la pertinence des tags proposés dans del.icio.us qui s'appuie sur l'effort de d'étiquetage de chacun). Ce potentiel là revient dans les mains du libre avec une véritable architecture distribué et avec des données libres si on souhaite les partager.
C'est le retour en force du libre sur les données.
Pour en revenir à notre utilisateur, comme il remet son destin entre les mains d'un tiers, le protocole et l'architecture doivent s'assurer que les données privées sont encryptées et fiables autant que possible. Le fait que l'infrastructure logicielle sur laquelle il s'appuie est une garantie supplémentaire de sécurité, même si elle n'est jamais totale.
Cette infrastructure et ce protocole doivent pouvoir aussi assurer un certain niveau de réplication des données pour permettre de pointer sur un noeud différent en cas de défaillance du noeud principal.
Tout ceci doit être contrôlable et configurable
L'étape ultime est la distribution des traitements.
Imaginons avec l'exemple de delicious que , un peu à la manière dont fonctionne le moteur de recherche Yacy (yacy.org) que lorsque je souhaite apposer un tag que non seulement la base de données qui associe les tags au urls soit répartie mais que les requêtes de suggestions de tags soient elles aussi séparées et distribuées pour être assemblée avant de me les servir.
Si je choisis d'héberger mon propre noeud, je peux optimiser en local et mettre à disposition les ressources à la puissance commune.
Si je suis un candide qui découvre un service ou que je suis nomade, un simple navigateur me suffit.
La puissance de calcul répartie à l'échelle du Web, finirait d'achever le "Web 2.0", celui qui fait que des organismes centralisent et enferment vos données dans un web conçu à la base pour être ouvert et distribué
I have a dream
Bon, je retourne me reprendre un peu de moquette.
Plus sérieusement, est-ce que quelqu'un qui s'est déjà penché dessus pourrait détailler un peu ce protocole "Open Collaboration Services" et les infras derrière .
S'agit-t'il d'une API REST, y at'il du XMPP ? Y'a t'il des hastables distribuées derrière, ...