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