[JDEV] Krufty Jabber Client

[arh14 at cornell.edu]

My (obviously incorrect) assumption was that Jabber clients would all 
implement a uniform interface and have the same services available.  
If/since this is not the case, then the Jabber protocol is truly a 
negotiation, and not a transfer protocol (except in the case of plain 
text messages, then).  Nevertheless, would it not be practical to build 
transports into the Jabber protocol?  Streaming media is the one case in 
which this would not be practical, and the one case I had assumed was out 
of scope for Jabber.  If a messaging mechanism is already in the Jabber 
protocol, is it really necessary to expect clients to support external 
protocols for transfer?  For non-streaming media is it not feasible to 
build rudimentary file transport into the Jabber protocol?  Otherwise, as 
a client, I would have to download and install every single transport to 
make sure I could recieve every type of message.  As a client, I simply 
might not like the idea of having to run all sorts of protocols 
[Jabber-client-based].

Sorry if I appeared to misread your post...I really did assume streaming 
media was way out of scope for Jabber.  As you say yourself there are 
already very good, efficient transport methods...which are usually 
already coupled with a negotiation protocol (Shoutcast, ICECast, 
RealMedia, whatever - they all already have clients and servers).

Aaron

On Mon, 9 Aug 1999, Patrick McCuller wrote:

> 	Please read my messages more thoroughly. I usually spend at least an hour
> composing each one. If you spent only a few minutes reading them, my time
> investment might pay off. Your message demonstrates a remarkable failure to
> understand my point. I have NEVER advocated that we should devote ANY time
> to reinventing ANYTHING. In fact I have devoted a fair amount of energy to
> trying to convice people on this list NOT to do this.

[lots snipped]