[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:
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
> 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
> > Patrick
More information about the JDev