[Standards] [LONG] Jeez, Sorry (was: All your problems, solved ; ))

[Rachel Blackman]

> 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 <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/