On Saturday 08 June 2002 02:22, Tijl Houtbeckers wrote: > Or clients that want to implement features that require the > transfer of small files (like icons or sounds) without wanting to > implement HTTP or HTTP server (after all one goal of Jabber is to > keep things simple for the client!).
On the one hand, I'm agreeing that implementing HTTP can become complicated, but on the other hand, for simple file transfers one probably doesn't need all those highly sophisticated features of the HTTP protocol - even HTTP/1.0 should suffice. Almost every programming language provides libraries for simple HTTP GET, the complicated part is HTTP POST with file uploads using MIME. I don't know HTTP PUT, but it should be much easier to implement. > This ofcourse still leaves the need for better p2p signaling. Best > would be ofcourse to combine both of them, letting both clients > indicate wich options they have and then choosing the best one > together. Maybe some discussion on how this signalling can be done > best is a good idea rather then argueing about wether inband is > good or bad.. I fully agree. The question is not, *if* one should use the server for file transfers or not, but *in what situations* it is best to use inband data, depending on the capabilities/attributes of the clients (and the server) and the actual load(s). Example 1: After a chat, I'd like to transfer a file to my friend, using DSL. He has only a 56K modem, has started three downloads and the network of his ISP is already on its knees. But the load on the jabber server is low and I wouldn't have any problems to transfer the file to the server. So I (or my client) uses the server. This solution is user-friendly, because I can go offline directly after transmission and my friend can first download the other three files and later decide to download mine. It is ISP-friendly, because I don't cause much traffic for my own ISP and if my friend is responsible enough to download the file somewhat later, it's better for his own ISP as well. Example 2: We're only chatting, my friend doesn't download anything else. The load on the Jabber server is high, almost nothing gets through. It is possible for my friend to establish a direct connection to my client's HTTP server and download the file. In this case, wouldn't that be the better solution? What I don't like about all that is: a) Although we want to implement an IM client, we're thinking about problems and asking questions how to implement the most efficient file sharing peer-to-peer application. b) The rules to be applied after the signaling you're talking about could become complicated. How far should we go? Determine them manually, once and for all, based on rather theoretical assumptions? Work on them based on empirical data gained from real networks? Invent a highly sophisticated algorithm based on statistics/machine learning which is able to adapt to changes in the network and to predict future network load, leading to better decisions? Wouldn't *that* go even far beyond HTTP, making things for clients highly complicated instead of keeping it simple? I think the problem here is that with any data (let's say three times) bigger than the average message a user would normally send to another user (by using a keyboard), we're more or less leaving the realm of instant messaging. Though applications can *use* the Jabber protocol for their own instant messaging needs (p2p, a2p, a2a), also leaving the area of pure GUI IM clients, nevertheless the Jabber protocol is (and should remain, IMO) an open protocol for instant messaging. Everything else is file sharing and those protocols are fundamentally different from IM. So either combine IM and file sharing in one app, but use different protocols underneath - or invoke a thirdparty app based on the URL the client got out-of-band, like browsers can invoke telnet when getting URLs like telnet://213.123.466.237 ... Bye, Marco _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
