XMPP needs, in my opinion, a way to negotiate real in-band
bytestreams. Base64 seems like a cop-out to me, it really does.
On the other hand, all XMPP clients already have a BASE64
implementation -- they have to, in order to deal with SASL for
logins. And even though BASE64 is a bloated method of encoding, when
using TLS you already have stream compression which cuts the size
back down pretty quickly.
BASE64 may be a cop-out in some ways, but there is logic behind the
choice. Which is not to say that different solutions may not be
worth examining, but you end up with a tradeoff between efficiency
and ease. In my experience, if a solution requires everyone to write
parsing for Yet Another Standard which has been shoehorned into XML
and stuffed into an XMPP stream, you are unlikely to see terribly
widespread adoption.
Not everyone has a T3 connection at home, some of us live in South
Africa, and well, bandwidth here is rather expensive: and so is a
static IP (yes, we differentiate between them here, we /actually/
have non-static ones too). When you have to weigh up the value of
1MB, you will know.
While low-bandwidth solutions are important, I think file transfer
over low-bandwidth connections is not a terribly widespread usage
case compared to normal file transfers. I am not averse to defining
some way to do a low-priority, low-bandwidth sending of a file, but I
am not sure that should be what general file transfer is designed
around.
This is not to say your usage case is invalid. But neither is mine,
and in the case of -fast- versus -size-, I know that for my own
situation I am going to want to get that 7 megabyte source drop from
my co-worker /quickly/ so I can get back to work, rather than shaving
482k off of the total bytes transferred but doubling the time it
takes to transfer.
(This is in addition to the negative-compression issues already
mentioned by Dave.)
3. Ultimately this protocol will smooth out the issues plaguing
Jabber regarding file sharing.
Not setting your sights high there or anything, I see. ;)
More seriously, I do not think there /is/ a silver bullet for Jabber
file transfer issues. There are simply too many usage cases in
general, and everyone has a different requirement. There is no
practical way to support every usage case in a single solution. (At
least, not one that I have seen proposed yet.)
A lot of protocols do it, hell, even your cellphone does something
similar (which is why you can call someone and surf over GPRS/3G/
HSDPA at the same time).
I digress, but... you cannot surf and call on GPRS at the same time,
generally. This is why if someone calls a GSM phone while you are
loading a webpage, they will generally go straight to voicemail. (Of
course, if they call a moment later when the page is done loading,
the phone will ring properly.)
I only mention this because as you draw the parallel between the two,
I wonder if I am misunderstanding the original suggestion. Are you
suggesting that something similar be done with file transfers, where
the message/iq/presence stanzas are placed aside entirely while the
stream is used for in-band transfers?
That is an interesting idea for low-bandwidth situations, though
seems to me a very high overhead to implement and I am not certain
how much practical gain there would be.
In regard to Dave's email, about the negative compression etc. very
true, didn't think of that. Nice, constructive criticism. Dave: the
very reason I thought of it was because a P2P connection isn't
always possible, as in my case (I don't need it, but the awareness
is there). I was hoping to use the server to host the Peer-To-Host-
To-Peer connection instead of some 3rd party website/ftp server.
Out of curiosity, if you are planning a server proxy for peer-to-peer
links, why is S5B insufficient? This is not a criticism, I am
genuinely curious about why DIME would work better with server-
proxying than S5B does.
I would think that even DIME would increase the bandwidth over S5B in
a case like that. After all, if the server is proxying anyway with
S5B you can send the data directly, no worries about having to
encapsulate the stream of data in anything at all.
You could even define an S5B extension which allows negotiation of
stream compression between any of the three points; that would allow
legacy clients speaking to a compression-enabled server to still just
send the data as-is, and have the server re-compress to send to the
bandwidth-limited recipient. That seems to me to alleviate bandwidth
concerns while still keeping backwards compatibility.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
