[JDEV] File transfer and Jabber

[mark at mjwilcox.com]

On 23 Apr 01, at 16:11, Jens Alfke wrote:

> 
> 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.
I spend most of life on the road with a sales force who loves to 
send attachments. 

I believe in URLs and Web servers. The ability to centrally store 
,replicate and manage that data is much more mature than in any 
other technology we currently have. 


> 
> > 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.
But that transport still has to go through SMTP, which just isn't 
efficient in my mind. 

I'm a "the right tool for the job" kind of man. Though I also see a 
day in the not-to-distant future where email and IM will be one & 
the same. 

And even with IMAP in place most IMAP clients still suck at this.

And I don't think there should be a reason to limit attachment size 
if I use my own quota (see below).

> 
> 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.
> 
Well at least we agree on something :).

> > 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
No, I'm assuming that people have access to a web-aware, 
networked file server as part of their ISP access. Instead of having 
to use FTP to publish, we use DAV which is built into more 
products (ie Office 2000), easier to secure than FTP (ssl over FTP 
never caught on) and with native access built into Windows & OS 
10, it's the file transfer protocol of the future.

I should have been clearer, the Web server would be mine. The 
space I consume, my own. You only have to consume yours if you 
want the file. 

I don't see forcing anyone to have another account. It does require 
some forward thinking by some people but it *could* happen. 

For example take a MyDocsOnline. They're one of the remaining 
free diskspace hosting services. Now imagine if they offered a 
Jabber service or they partnered with a Jabber service with shared 
accounts. 

You have a jabber client who understands this type of arrangement:

User clicks send file. 
GUI prompt for file
File is transfered via DAV to client's account on MyDocsOnline to 
public space (though there could be provisions to make this private)
URL is transmitted to recipients.

This way the resources consumed are the sender's not the 
recipients. If the sender hits a quota, the provider can have 
provisions to add more. Or the sender can delete older files.

Now the biggest gotcha in the arrangement is the fact that if the 
sender deletes a file before a recipient got it. 

But you could come up with a system that keeps a list of who was 
supposed to get the file and who has actually retrieved it. Then 
when the sender attempts to delete the file, they could be notified 
that not everyone has seen it yet. Or the service provider could offer 
an archival service. 

The one situation I haven't really thought too much through is the 
firewall situation, but then sending files via jabber to get through a 
firewall, is really a security hack anyway, in the same way all of 
the current Web services (ie RMI over HTTP, XML-RPC) are using 
HTTP to tunnel through a firewall (kind of makes you wonder why 
you spent the $$ on them in the first place :). Which is an entirely 
different discussion.

I know I'm out on a limb. I'm just tired of people penalizing my 
INBOX quota (and don't want this to continue when more people 
start moving to IM) for sending me files I haven't requested when we 
have viable alternatives.

Mark


> 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
> 


Mark Wilcox
mark at mjwilcox.com
Got LDAP?