Pour le partage de documents il existe deux façon de faire, soit tu fait un espèce de P2P entre les deux clients, soit tu balance ça sur un serveur et tu file une url (plus simple à implémenter), la première est standardisé l'autre c'est juste un hack :)
On peut imaginer un serveur (pas un p2p) qui utiliserait le protocole de son choix (https, sftp), mais qui aurait aussi une identité sur le réseau XMPP.
Cette identité serait capable de fournir l'url du contenu s'il est déplacé.
l'utilisateur illwieckz@toto.net fait héberger ses photos par le service photosharing.com.
Le service photosharing aurait un compte bot@photosharing.com, il possède un portefeuille d'identifiant, et peut servir la photo associée sur un quelconque miroir sur un quelconque protocole.
Quand illwieckz@toto.net ajoute une photo sur le serveur photosharing.com, les photos sont hébergées sur photosharing.com, mais le portefeuille d'illwieckz.net contient une entrée photo (illwieckz@toto.net)/uuid-111-222-333.jpg qui est un alias vers (bot@photosharing.com)/uuid-111-222-333.jpg
On a toujours un système client/serveur (compatible pour la masse), mais on n'est pas limité à garantir l'a pérennité d'une url.
Après on peut imaginer que le client fasse cache ou bien que movim.eu duplique la photo sur http://cdn.movim.eu et l'annonce à photosharing.com, on en viendrait à développer un p2p, mais là encore, le système serait utilisable même si le client ne fait pas p2p smartphone par exemple).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: bosh?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 8.
On peut imaginer un serveur (pas un p2p) qui utiliserait le protocole de son choix (https, sftp), mais qui aurait aussi une identité sur le réseau XMPP.
Cette identité serait capable de fournir l'url du contenu s'il est déplacé.
l'utilisateur illwieckz@toto.net fait héberger ses photos par le service photosharing.com.
Le service photosharing aurait un compte bot@photosharing.com, il possède un portefeuille d'identifiant, et peut servir la photo associée sur un quelconque miroir sur un quelconque protocole.
Quand illwieckz@toto.net ajoute une photo sur le serveur photosharing.com, les photos sont hébergées sur photosharing.com, mais le portefeuille d'illwieckz.net contient une entrée photo (illwieckz@toto.net)/uuid-111-222-333.jpg qui est un alias vers (bot@photosharing.com)/uuid-111-222-333.jpg
Si edhelas@social.net veut voir la photo (illwieckz@toto.net)/uuid-111-222-333.jpg le serveur "toto.net" transmet la demande à bot@photosharing.com et photosharing.com lui sert https://dl.12345.mirror.cdn.photosharing.com/uuid-111-222-333.jpg
Quand edhelas@social.net tagge vincent14@movim.eu sur la photo (illwieckz@toto.net)/uuid-111-222-333.jpg
social.net envoie sa requête à toto.net et movim.eu, si les paramètres de confidentialité de chacun le permettent, alors la tag est enregistré dans les portefeuille de edhelas@social.net.
À cet instant le serveur movim.eu copie ce tag dans le portefeuille de vincent14@movim.eu (idem pour illwieckz@toto.net), le client vincent14@movim.eu reçoit une notification, demande la photo (illwieckz@toto.net)/uuid-111-222-333.jpg et photosharing.com lui sert https://dl.54321.mirror.cdn.photosharing.com/uuid-111-222-333.jpg. Son client affiche la photo et le tag au bon endroit.
On a toujours un système client/serveur (compatible pour la masse), mais on n'est pas limité à garantir l'a pérennité d'une url.
Après on peut imaginer que le client fasse cache ou bien que movim.eu duplique la photo sur http://cdn.movim.eu et l'annonce à photosharing.com, on en viendrait à développer un p2p, mais là encore, le système serait utilisable même si le client ne fait pas p2p smartphone par exemple).
ce commentaire est sous licence cc by 4 et précédentes