[JDEV] Krufty Jabber Client

[Patrick McCuller]

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

	My refutation was already in the message you replied to, and I am quoting
it below again. Pay particular attention to the third paragraph.

	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.


Patrick