[JDEV] Krufty Jabber Client

[arh14 at cornell.edu]

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

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

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.

Aaron