[JDEV] File transfer and Jabber
jens at mac.com
Mon Apr 23 18:11:14 CDT 2001
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 3659 bytes
Desc: not available
More information about the JDev