[JDEV] Feature negotation/File transfers..
Thomas D. Charron
tcharron at my-deja.com
Mon Aug 9 13:25:47 CDT 1999
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
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.
>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.
>Client B: I support ZIP and GZIP.
>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.
>Client B: Alright, connect at: 22.214.171.124......: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..
--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.
More information about the JDev