[JDEV] file transfers (was: Krufty Jabber Client)

[Jeremie]

Thank you!  YES!

Below in what Patrick wrote is VERY close to what I've mentioned long ago
on the topic of file transfers, and is the heart of the File Transfer
proposal that I'll be posting.  I'll post the proposal hopefully yet today
and we can start discussing it further from there.

Jer

> 	My point is, again, that there are plenty of really good ways to move
> various kinds of data from point A to point B. FTP, HTTP, RealMedia... these
> are well developed mechanisms with available interfaces. There's simply no
> need to reinvent or repackage this material. And trying to do so would be a
> foolish waste of time.
> 
> 	So where does Jabber fit in? The Jabber protocol can help clients to figure
> out how to initiate the transfer of data. For instance: the user of Client A
> wants to start streaming audio to the user of Client B. Now, we have a few
> options as to how we should handle this in Jabber, some of them comically
> ridiculous. We'll assume that the clients will be using some kind of direct
> client to client transmission, instead of wasting server time with it. Our
> options? I'll look at two of them:
> 
> 	1. Establish an XML stream protocol - like or unlike the client to server
> protocol - between the two clients. Package every byte of the streaming
> audio into the XML stream (using an encoding methods, because XML doesn't
> really have a good way to encapsulate purely binary data, CDATA Sections
> being its closest call, but even they must be encoded to avoid certain
> character combinations).
> 	This is a silly approach. That should seem pretty obvious for streaming
> media: our Jabber protocol - and derivatives thereof - are not optimized for
> streaming audio, video, or anything like it.
> 	What may be less obvious is that it is also a silly approach even for file
> transfers. Why? Because HTTP, for instance, is already pretty damned good at
> this, and it will get better all on its own without our help. We need merely
> plug in our libraries to make it happen. HTTP is just an example. There are
> many ways to move files - and indeed any form of data. We don't need to
> concern ourselves with this.
> 	There is one possible exception to the let's-not-invent-our-own-wheel
> principle in this area. And that is in the case of our own particular wheel:
> the Jabber protocol. It may be that the Jabber protocol, or a subset of it,
> is a great way for clients to communicate instant messages and other Jabber
> protocol goals directly to each other. This idea is probably worth pursuing.
> 
> 	2. Establish a non-protocol-biased framework for clients to negotiate
> client to client transfers. This is feature negotiation and it may work
> pretty well. Let's start with a concrete example of a possilbe interaction
> between clients. This is assumed to me sent through the Jabber transport:
> client to server to client, and it is also written in English for maximum
> clarity.
> 
> 
> Client A: Hi, I want to send you a binary file.
> Client B: OK, how about HTTP?
> Client A: Alright. Pick up the file at
> http://102.102.102.102.102.102.102:45000/file_6_6_4.tgz
> 
> another example:
> 
> Client A: I want to send you an MP3 audio stream.
> Client B: Sorry, I can't support that.
> 
> another example:
> 
> Client A: I want to send you a RealText stream.
> Client B: Alright, where do I pick it up?
> Client A: Pick it up at pnp://102.102.102...../etc/etc/etc/
> 
> [or]
> 
> Client A: I want to send you a RealText stream. Pick it up at
> pnp://102.102.102...../etc/etc/etc/
> Client B: Alright.
> 
> another example:
> 
> Client A: I want to send you a JPG image.
> Client B: Don't. I am a toaster.
> 
> another example:
> 
> Client A: I want you to send me hash receipts.
> Client B: OK, how about SHA-1 hashes?
> Client A: No. I can support MD5 hashes.
> Client B: OK, I will send you MD5 hash receipts.
> 
> another example:
> 
> Client A: I want to compress my messages to you. I can use ZIP, GZIP, and
> Bob's Cool New Compression.
> Client B: I don't support compression. I am a wristwatch.
> or:
> Client B: I support ZIP and GZIP.
> 
> another example:
> 
> Client A: I want to start a Jabber session directly with you.
> Client B: Sorry, I'm behind six firewalls and a cauldron of boiling oil.
> or:
> Client B: Alright, connect at: 102.102.102.102......:5222
> 
> 
> 	I hope this servers to clarify my position. In summary, I think that a
> feature negotiation mechanism is all clients need to start client to client
> transfers. Whether the feature negotiation occurs on a
> query-this-then-query-that basis or on a
> here's-everything-I-can-handle-do-your-worst all at once exposure, it should
> work out about the same architecturally.
> 
> 
> Patrick
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>