Oui c'est sûr, si t'as un cas idéal où tout le monde laisse tout passer, et si t'acceptes tout le bordel qui va avec (base64, stockage du fichier à chaque étape, transfert à recommencer depuis le debut si ça foire, et y'en a sûrement d'autres que j'ai pas en tête), ça peut marchoter.
Avec XMPP le fichier passe par un canal dédié, peut être stocké ailleurs que le reste du message, y'a pas d'augmentation de taille, et même si y'a un quota au milieu tu peux toujours faire un P2P.
Okay, donc avec XMPP aussi, si je comprends bien, ça marche dans un cas idéal, à savoir le cas où l'expéditeur et le récepteur sont connectés au même moment.
Base64 : ça dépend du MUA (si son auteur a décidé de forcer à encoder en base64) car ça doit faire 15 ans que les MTA sont capables de passer du 8-bits sans accroc.
Stockage intermédiaire : si tu n'es pas dans le cas idéal en XMPP, il faut bien que ça soit stocké sur un serveur. Donc même raison pour mettre des quotas qu'en SMTP.
Reprise de transfert : bien, mais ça implique que les serveurs stockent pendant un certain délai les morceaux de fichiers dont le transfert est inachevé. Devrait influer négativement sur les quotas.
[^] # Re: Toujours le même problème: centralisation
Posté par gnx . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 1.
Okay, donc avec XMPP aussi, si je comprends bien, ça marche dans un cas idéal, à savoir le cas où l'expéditeur et le récepteur sont connectés au même moment.
Base64 : ça dépend du MUA (si son auteur a décidé de forcer à encoder en base64) car ça doit faire 15 ans que les MTA sont capables de passer du 8-bits sans accroc.
Stockage intermédiaire : si tu n'es pas dans le cas idéal en XMPP, il faut bien que ça soit stocké sur un serveur. Donc même raison pour mettre des quotas qu'en SMTP.
Reprise de transfert : bien, mais ça implique que les serveurs stockent pendant un certain délai les morceaux de fichiers dont le transfert est inachevé. Devrait influer négativement sur les quotas.