[JDEV] File transfer and Jabber

[Jens Alfke]

On Monday, April 23, 2001, at 07:14 AM, Iain Shigeoka wrote:

> I believe that if Jabber client developers want to see Jabber grow to 
> the popularity of a system like AIM we need to consider what a Jabber 
> system with 1 million users would look like and how to make that 
> practical.

On the other hand, one of the goals of Jabber is to be more distributed, 
so that unlike existing monolithic services, not everyone in the world 
has to connect to the same server. Your ISP will have a Jabber server, 
my employer will have one, et cetera. There may be huge ISPs that have 
millions of users, but they already have phat pipes and massively 
replicated servers.

> In-band file transfers are just not feasible using this approach.

Again, I disagree. The Jabber architecture is very much like SMTP, and 
SMTP servers have been handling "in-band" file transfers for decades. 
Even huge ISPs and mail services accept file enclosures, although they 
may impose limits on the file size.

> How about this for a proposal.  Define specifications for a separate 
> oob server.  To make it simple to convert any web server into a 
> compliant oob server, we define the system using only httpd.  It 
> accepts file uploads given authentication, and allows file downloads 
> using temporary URL links.

I don't see how this does anything but move the supposedly-intolerable 
burden of file transfer from one server onto another.

In any case, if we do design a relay server, I would prefer to see a 
more efficient solution where the server directly streams data from one 
client to another rather than having to store-and-forward the entire 
file.

>  Part of the standard should be incentives to run oob servers by people 
> other than Jabber.

Well, this just sort of sweeps the issue under the rug by making it 
someone else's responsibility.

And anyway, who are "people other than Jabber" Or rather, who is 
"Jabber"? Jabber is a service that anyone can run. I repeat: when Jabber 
takes off it's not just going to be jabber.org and jabber.com hosting 
everyone in the world. Jabber will be a distributed piece of the 
infrastructure just like SMTP or HTTP.

In general I think this fear of in-band transfer performance is a 
classic example of premature optimization. When you're designing a large 
system you don't start off by guessing that something is going to be a 
bottleneck and immediately build an optimization ahead of time instead 
(especially not an optimization, like jabber:x:oob, that handles only 
the special case without firewalls or NAT). You build the basic, most 
robust case, then if it does turn out to be a bottleneck you add 
optimizations for specific circumstances.

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