[JDEV] Krufty Jabber Client

arh14 at cornell.edu arh14 at cornell.edu
Mon Aug 9 09:53:05 CDT 1999

Ahh, doh...CTCP=Client-To-Client-Protocol.  And here I've been 
cross-babbling about the desire for some client-client protocol ;p

On Sun, 8 Aug 1999, Scott Robinson wrote:

> ZModem? :) Actually, as you may have noticed from my _need_ to use
> pre-existing code, I love triple-R'ing code. However, I believe in the case
> of CTCP, we may need to create a new spec. I only say this because Jabber is
> a XML paradigm. I know of no CTCP protocols that are based on XML. In that,
> I would have a severe problem with talking to the server in XML, but
> developing some CTCP protocol that isn't.

Whoa whoa whoa...why *can't* client-client be XML-based??  Each client 
recieves XML-based messages from the server...each client is in itself 
both a client AND a server (it must send and recieve messages), and knows 
how to handle the XML messages.  The protocol should be the same.

> > > > 	I suggest that plain vanilla messages be sent as text in the body
> > > > of the message statement only. This will reduce traffic. The MIME
> > > > extension should probably remain silent on these. For other types of
> > > > media, how about something like this:
> > > >
> > > > <ext>
> > > >  <MIME>
> > > >
> > > >  </MIME>
> > > > <ext>
> > > >
> > > > 	Seems simple enough, what do you think?
> > > >
> > >
> > > Seems just fine. In the case of a MIME bearing message, I would suggest
> > > placing in the message text body either the description of the
> > > MIME message
> > > or a notice saying "this is a MIME message and you'll need <advertised
> > > client> to read it." Probably both would be best!
> > 
> > 	I thought I made this point pretty clear: clients should NOT encapsulate
> > messages in MIME unless ABSOLUTELY neccessary. Why is that? Because
> > otherwise, Super-Complex Client A will be unable to communicate with
> > super-simple client b. Jabber clients must be allowed to be simple. Putting
> > a "You can't read this! Nyah!" in the message body for a text/plain MIME
> > message is sheer folly. It increases network traffic needlessly, and
> > alienates simple clients.
> > 
> > 	Remember, k.i.s.s.
> > 

Well, MIME is really not heavyweight.  The difference between a plain plain- 
text message and a MIME plain-text message is two lines, like:

Boundary: ----foo----
Content-encoding: plainttextfoo

I don't see any reason that even the simplest client couldn't manage to 
put this in.  /Anyway/...a message type attribute would be really simple:

<message encoding=offthewallencoding type=MIME>


<message encoding=foo type=plain>


<message> (default encoding=ISO-8859-1?, type=plain?)

I think this would be a better solution than adding a <MIME> element. 
(Warning: IANAJD - I Am Not A Jabber Developer ;)  I hope your readers don't 
strip the angle brackets.

> Good point. Message text contains a ASCII'fied version of the MIME encoded
> message. There may be duplication, but it keeps true to both standards.
> Either way, I hope that in a further version of the Jabber spec we support
> compression. (I would suggest adding it in about the time we get encryption
> working) Compression of course killing the worry about duplication.

Well, if you want to do compression, then wouldn't standardizing on MIME 
be the solution?:  Content-encoding: application/gzip?  Does this make 
sense?  I only profess a modicum of MIME knowledge.  IMHO, MIME is a good 
solution for extensibility.  IMHO, introducing TWO versions of messages 
(MIME, not MIME) might be more trouble than just standardizing on MIME.  
I would like to hear the arguments against MIME if there are any, because 
I am not a MIME expert.

> > > Krufty. ;) BTW, I don't have the address for JabberBeans. Is there anyway
> > > you could send it to me? I've decided I'll be implementing my own C Jabber
> > > library, and modeling it after JabberBeans would make moving between
> > > platforms for developers much easier. -- Speaking in the blind
> > > here, I would
> > > suggest adding MIME straight into the main library, only because it should
> > > become the "standard" transport and normal text messages just come to the
> > > client as a MIME message with only one text part.
> > 
> > 	Again, about MIMEing straight text: Do not do this. Put a MIME declaration
> > in the MIME extension if that tickles your fancy, but don't require clients
> > to support MIME. I like MIME as much as the next guy, and maybe every client
> > on earth will support it, but jabber's basic design principle of k.i.s.s.
> > for the client pretty much precludes requiring MIME.

Supporting MIME basically means just separating a message by Boundary 
lines, which is pretty much negligable, and displaying them according to 
the Content-encoding specification (helpfull).  Also, in this way whoever 
wants to send HTML will send it as Content-encoding: text/HTML.  The 
client will "know" what type of message is coming in.  The Spartan client 
can strip tags or something, right?  I really don't see MIME as a complex 
or bloated thing.  You don't even need a MIME library per-se to support 
MIME...just include the rudimentary lines and you're set.  I have even 
sent MIME messages manually by telneting to an SMTP server...it's not that 
big a deal.

> > 	JabberBeans itself seems to work fine, though it is by no means finished.
> > There's no high level documentation, there is no complete working example
> > client, and the integrated test suite is not complete. There is a fair
> > amount of JavaDoc, which I've been working at pretty steadily, and that
> > should help. Its API probably won't change wildly after this, excepting
> > changes to protocol objects just as Messages or what have you that jabber
> > may amend from time to time.
> > 
> > 	As for using it as an example for building a C or C++ (you seem to prefer
> > straight C, right?) library, I don't know how much it will help you. You're
> > welcome to try. But JabberBeans is in Java, and makes full use of the object
> > oriented paradigm. Er, to overuse a phrase.

JabberBeans could also take advantage of the JavaMail extension if/when 
using MIME.  Not to mention util.zip, etc., etc.  You can tell I'm a Java 
bigot ;)


> Well, with Kruft coming I'll end up coding C++, but I do prefer C. If in the
> very least, I can see an example API and maybe improve/create a derivative
> work.
> > 
> > 
> > Patrick
> > 

More information about the JDev mailing list