And of course you can always develop some sort of WebDAV or http hosting to store files for file transfers. I know Jabber Inc. has this setup with their client, Jabber Instant Messenger.
Mike Oliver wrote: > Why have just one protocol? > > SMTP does pretty well at file transfers that are asynch. The Jabber > protocol can include a header for the attachments and the user at the > other end can decide if they want to download the file. The a request > can then be sent to the originating peer and an SMTP transfer begun and > the remote client can notify the user when the transaction is complete > by asking where to put the file. There are SMTP libraries in almost > every language you can name, so this doesn't appear to be a big problem. > > FTP is another and offers the ability to transfer files without the > base64 encoding. > > Ollie > > At 11:45 AM 6/5/2002 -0400, you wrote: > >> In-band transport of large payloads is something we and others have been >> looking at pretty intensely. Obviously it would be a nice thing to have, >> but it is also very, very difficult to do properly. If you just stick >> base64 in an X element, you have huge problems because if that takes 10 >> minutes to transmit, you can't send anything else for those 10 >> minutes. You >> could chunk them, but that hardly makes things simpler for the client >> software. This also makes it massively more difficult to distinguish >> legitimate traffic from a denial of service attack. Furthermore, it means >> the server has to do a whole lot more XML processing (which may >> already be >> a bottleneck), because all XML content has to be at least checked for >> well-formedness. To speak nothing of the bandwidth implications. >> >> Ultimately, I don't believe there is a satisfactory way to transport >> large >> payloads in-band while keeping things simple for the client. The solution >> to this problem will involve a more complex system on the client >> endpoints >> - though not necessarily in typical client software. >> >> -Mike >> >> >> >> |---------+----------------------------> >> | | Andy Beetz | >> | | <andy.beetz@clear| >> | | swift.com> | >> | | Sent by: | >> | | jdev-admin@jabber| >> | | .org | >> | | | >> | | | >> | | 06/05/2002 10:29 | >> | | AM | >> | | Please respond to| >> | | jdev | >> | | | >> |---------+----------------------------> >> >> >>------------------------------------------------------------------------------------------------------------------------------| > >> >> | | >> | To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> | >> | cc: | >> | Subject: [JDEV] File transfers | >> | | >> | | >> >> >>------------------------------------------------------------------------------------------------------------------------------| > >> >> >> >> >> I've set up jabberd and got a couple of clients connecting to it >> (winjab). >> I >> tried a file transfer which worked no problem. What I saw looking at the >> Winjab source is that the receiver downloads the file from the sender on >> it's own socket based connection. >> >> I'm just thinking that there should be a better way to do this and inside >> the message. I'm not saying my idea is the best or anything, but I do >> think >> that it would present the client authors with less headaches. Anyway, my >> idea is that a message element can have a child, let's say attachment or >> even an x, which will contain the contents of the file. XML can handle >> this >> if the file is base64 encoded, as it ends up as plain text. >> >> Just some thoughts >> Andy Beetz >> >> >> >--------------------------------------------------------------------------------------------------------------- > >> >> >> Clearswift monitors, controls and protects all its messaging traffic in >> compliance with its corporate email policy using Clearswift products. >> Find out more about Clearswift, its solutions and services at >> www.clearswift.com. >> *********************************************************************************** >> >> >> This communication is confidential and may contain privileged >> information intended solely for the named addressee(s). It may not >> be used or disclosed except for the purpose for which it has been >> sent. If you are not the intended recipient, you must not copy, >> distribute or take any action in reliance on it. Unless expressly stated, >> opinions in this message are those of the individual sender and not of >> Clearswift. If you have received this communication in error, please >> notify Clearswift by emailing [EMAIL PROTECTED] quoting the >> sender and delete the message and any attached documents. Clearswift >> accepts no liability or responsibility for any onward transmission or use >> of >> emails and attachments having left the Clearswift domain. >> >> This footnote confirms that this email message has been swept by >> MIMEsweeper for Content Security threats, including computer viruses. >> >> _______________________________________________ >> jdev mailing list >> [EMAIL PROTECTED] >> http://mailman.jabber.org/listinfo/jdev >> >> >> >> >> >> _______________________________________________ >> jdev mailing list >> [EMAIL PROTECTED] >> http://mailman.jabber.org/listinfo/jdev > > > Michael Oliver > Chief Technology Officer > AppsAsPeers.com > 7391 S. Bullrider Ave. > Tucson, AZ 85747 > 520.574.1150 > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev -- Nick JabminRPC Developer JabberSMTP Developer ChatBot's B1tch _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
