[JDEV] Feature negotation/File transfers..

[Thomas D. Charron]

  To start, this is a REALLY good post..  Albeit a bit long..

On Mon, 9 Aug 1999 13:39:42    Patrick McCuller wrote:
>	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.

  This was the primary point when Jer suggested using HTTP transfers..  Already there, proven, and available to everything, right down to toasters.. ;-P

>	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:

  Doesn't matter, either way works, going thru servers or going thru CTCP..  Client answers either way..

>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

  Almost EXACTLY the example used several months ago..

>Client A: I want to send you an MP3 audio stream.
>Client B: Sorry, I can't support that.

  Yep, one example of feature negotiations..

>Client A: I want to send you a JPG image.
>Client B: Don't. I am a toaster.

*ROTFL*

>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.

  Yet another feature negotiation example..  Same would be:

Client A: I want to send you a file.  I prefer MIME encoding via Jabber stream.
Client B: Unsupported in this client.  I prefer HTTP download..
Client A: Unsupported in this client.  My secondary preference is UUENCODE Jabber stream.
Client B: Can do, here comes, conversation ID: 17826482

  This case would assume it was a file transfer, and not some stream or anything..

>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.

  Yep, exactly..

>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.

  YES.. ;-P

>Client B: Alright, connect at: 102.102.102.102......:5222

  You've GOT it..

>	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.

  This is a VERY good message on what our original intent was on file transfers..  Different transfer methods are good under different circumstances..  DEFAINTLY a good demo of what we mean when we say feature negotiation..

---
Thomas Charron




--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.