[JDEV] Krufty Jabber Client
arh14 at cornell.edu
arh14 at cornell.edu
Mon Aug 9 12:12:43 CDT 1999
On Mon, 9 Aug 1999, Eric Crahen wrote:
> > Exactly. The Jabber protocol should be the Jabber protocol. PLEASE
> > let's NOT create a separate protocol for each client! That's what Jabber
> > was supposed to solve, right? I see no reason why CTCP can't be
> > identical to CTSP. The addition is that CTSP handles event notification
> > (buddy online, etc.) while client won't. But there is no reason to
> > create two parallel protocols. For instance, keeping one protocol would
> > allow a client to "proxy" for another (for whatever reason you'd want to
> > do that).
> I agree, jabber should no tbe concerned with MIME types or any of the client
> oriented CTCP protocols. Isn't he porject designed as a server based XML
> stream? Since this is the case, the client will all have XML parsers built
> in, so why not just define a CTCP standard for attempting to initiate an XML
> stream to another client - this way at least all the clients can talk to one
> another and they'll be guided by a common CTCP protocol.
I see no difference between CTCP communication and CTSP communication.
Whey even have two XML-based protocols? Just have one. Clients will
just refrain from sending status messages, and disregard them from other
clients. I think there should be a common Jabber protocol that is both
client to client and client to server. Remember, each client is a server
also...in this world there is no such thing as a pure client anymore.
> I really see no advantage to trying to make MIME stuff happen between
> clients, that gets a little bit nuts. If we end up with email transports
> that read MIME sources it should simply convert them to an XML stream as
I only advocate MIME because the alternative is to reinvent the wheel by
hardcoding into the Jabber protocol yet another unique way to send
heterogenous data. MIME is there, and is used, and works. If there is
to be sending of heterogenous data at all, then it would make more sense
to use something that already enables it. On the other hand this could
easily be solved by not supporting the sending heterogenous data at all.
> > > Jabber client to server is an XML streaming protocol, but that doesn't
> > > constrain the client to client. Sure, it might be nice to reuse the 'xml
> > > hardware' that the client's already got, but then again, there are other
> > > approaches. For instance, Jer has an example in one of his feature
> > > negotiation proto-proposals that indicates that *each kind* of client to
> > > client interaction may have or use its own protocol.
> I think people should be careful about getting too deep into this file
> transfer and MP3 stuff. That gets a little bit crazy I think. Jabber itself
> it seems should mainly be concerned with lightwieght XML streams to unify
> communications. The clients should just make an MP3 plugin if they want to
> that stuff, but it seems that gets outside the actual scope of Jabber
Right, the Jabber protocol should unify communications. I see that as
client/server transparency. Whoever you are sending to is a client.
Whoever you are recieving from is a server. The Jabber "server" per-se,
just happens to proxy messages to other users.
Although I am a purist at heart, I don't think a universal messaging
system will be practical unless it allows the transmission of
heterogenous data. I don't use ICQ all that often for several reasons,
but when I do, I often like the convenience of sending files to other
people in the middle of a discussion. To completely abandon this aspect
would really cripple use of Jabber IMHO.
If clients are to be heavyweight enough to be able to parse XML, they can
surely handle MIME. MIME itself is trivial...the philosophical
consequences of actually using its capabilities to send files around is
another question entirely.
> How complex of file transfers are we talking about? We don't want to get off
> track and start to build a client that basically does
> email/ftp/http/icq/aol/etc :)
> Since this stuff will happen as various clients get created, we should
> consider some XML based standard I think though.
Jabber should provide the *transport* IMHO. Without the transport
ability, people will either be resigned to use some third party transfer
program (FTP, whatever), or figure a way to add this functionality into
their client in a peculiar, non-standardized way. Best to add the
transport capability into Jabber itself so this does not happen.
Think about this:
If Jabber does not support MIME, what is stopping somebody from typing
up a MIME message and just sending it as a plain text Jabber message to
be interpreted at the endpoint? I can base64 my MP3 add a MIME header
and send it off to my friend Joe. This is doable but ugly, so I suggest
MIME be part of the Jabber protocol.
More information about the JDev