[JDEV] Krufty Jabber Client

[Scott Robinson]

Interleaved response.

Are you meaning to send only to me?

Scott.

* Patrick McCuller translated into ASCII [Sun, Aug 08, 1999 at 04:57:56PM -0400][<007501bee1e0$b0684560$1b76c897 at scylla>]
> 
> > From: Scott Robinson [mailto:scott at tranzoa.com]
> >
> > > 	As for Client to Client protocols: Jabber was originally designed
> > > as it is, client to server, on purpose. It may be that a client
> > to client
> > > protocol would be a separate protocol.
> > >
> >
> > I understand that CTCP goes against the Jabber "mission
> > statement" as it is.
> > However, as has been shown in the past, people will find a use/something
> > that can only use CTCP... I'm suggesting we write, at least, an official
> > recommendation as to how CTCP could be implemented.
> 
> 	Alright, I see what you're saying. Clients *will* talk to each other
> directly, so let's start something to support that. Fine. But let me make a
> suggestion:
> 
> 	Reduce, reuse, recycle.
> 
> 	That is, if you're going to transfer files, look for something that already
> does that pretty well, and use it. If you're going to implement 1:1 chat,
> look for something that does that well and use it. And so on.
> 
>

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.
 
> >
> > > 	You've probably looked at the protocol closely enough to know that
> > > MIME messages go in the <ext> message extensions. This is itself an XML
> > > document fragment. Jeremie has been slow to produce a draft standard on
> > > this, though he claims he has one on the back burner. Honestly, Jer's
> > > absenteeism is what's slowing down jabber.
> > >
> >
> > If Jer's slowing us down (I wouldn't know one way or the other)
> > then we can
> > take it into our own hands. User-controlled and splintered FTPs and web
> > pages, while not the most efficient way to burn time, at least get us
> > working. -- I'm not experienced with XML to a level I'm happy
> > with, yet, but
> > I will be trying to work in many of my suggestions to a new DTD. I figure
> > that at least having a portable document available for developers places
> > Jabber one step closer to completion.
> 
> 	I did NOT say or imply that Jer slows 'us' down. Jer is what keeps jabber
> going at all. What I did mean to say is that Jeremie could do better by
> paying more attention to JDEV and the jabber developers. He does a lot - an
> aweful lot - but in this explosive last few weeks, he has been playing with
> web servers behind the scenes. That's not a bad thing! It does have to get
> done! And he's no doubt busy besides. I'm not blaming or judging him in any
> way; merely asserting that the jabber community needs some better
> organization ASAP.
> 

Oh, ok. =D -- Hey Jer, how about adding some of us to your crew? We'd _love_
to help you in your administration blues!

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

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.

> >
> > 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.
> 
> 	There is no address for JabberBeans. Those interested can join the
> JabberBeans development list at
> http://www.egroups.com/groups/jabberbeans-dev/. I'll put the alpha in the
> vault there. I'm going to create a JabberBeans announcement list and a
> discussion list as well, because I perceive the three as separable topics.
> 

Thanks!

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

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
>