[JDEV] File transfer and Jabber

[Jens Alfke]

On Monday, April 23, 2001, at 09:52 AM, mark at mjwilcox.com wrote:

> I think using Jabber to send files is a waste of bandwith and time.
> Look, email attachments were a bad thing.

Wow, I work on email in my day job and that's an unusual opinion I've 
never heard before, even from people who generally hate MIME.

> Attachments waste bandwith, disk space and you force every user
> who you send the message to, to consume network resources
> *even* if they don't want to.

First off, even with regard to email this is not true. Most mail clients 
nowadays let the recipient choose whether to download large attachments, 
either by limiting the size of a POP download or by using IMAP's more 
sophisticated mechanism to retrieve individual MIME bodies on demand.

Secondly, I definitely agree with you that in-band Jabber file transfer 
should never be driven by the sender. I said this very clearly and 
emphatically yesterday. The receiver should send <iq> queries to 
retrieve chunks of the attachment.

> Instead of sending actual data around
> the jabber network, send URLs to files on a Web server. If I want to
> read your file, I'll download it.

This is simply an accounting trick that wastes someone else's disk space 
and network bandwidth, namely the owner of the Web server. It's 
everything you said you hate about email enclosures except that you 
replace the word "SMTP" with "HTTP" (or "WebDAV"). They have to host the 
file for you, regardless of whether the recipient wants it, and if the 
recipient doesn't request the file immediately, the server has to hang 
onto it for some unknown period of time before getting rid of it, which 
incurs extra administrative overhead (they have to have some kind of 
daemon nuking expired files.)

Then we also have issues of preventing abuse by imposing quotas on 
users, which implies the Web server has to require you to log in to 
upload, which means you have to have Yet Another Damn Account somewhere. 
It also means that if you fill up your quota, you can't send any more 
files to anyone until the recipient of the last one hurries up and 
downloads the file ... and maybe she's watching TV instead, or 
downloading over a 14.4 modem, and you'll just have to wait the full 
half hour or whatever until the server expires the file and restores 
your quota.

It also doubles the time to send a file since the sender has to finish 
uploading it before the receiver can download it.

It also makes Jabber more confusing to set up and use. "I know you 
already have a Jabber account, but you can't send me a file until you 
also get an account on a WebDAV server and go through a preference panel 
in your client to tell Jabber about it..."

Have I rattled off enough reasons why this is a bad idea that doesn't 
actually help anything? Or should I take five minutes to come up with 
some more?

If people really, really insist on using an out-of-band mechanism to 
send files, please at least use one that isn't store-and-forward. As I 
said earlier, the sender and receiver can open a socket to a relay 
server and have the server stream the data across.  This imposes 
virtually no disk or CPU overhead on the relay server, and allows the 
file to be sent immediately without any forwarding delays.

—Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3659 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010423/ff5b0786/attachment-0002.bin>