[JDEV] Krufty Jabber Client

[Patrick McCuller]

> >
> > 	Reduce, reuse, recycle.
> >
> 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.

	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 would suggest you
start by making a list of the kinds of client to client interactions you can
think of, and then address each of them by determining whether an existing
protocol delivers it very well, or it whether it needs to get rolled into a
new protocol.

	A more concrete example: streaming media. There are already very good,
efficient transport methods for various kinds of streaming media, and trying
to encapsulate the media itself would probably - I'm sure you'll agree - be
a very bad idea. However, a protocol for negotiating the connection -
passing IPs, proxies, URIs, and media types around might not be a bad idea.
That itself is essentially feature negotiation and I've been trying to poke
Jer to spill the beans on what he's been doing with this concept.  :)

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

	Indeed, perhaps, but remember the simple client principle. Clients can't be
expected to do encryption and compression, can they? Well, perhaps they can,
but we should keep in mind that it is probably best to at least initially
implement this kind of thing as an extension. Client->server->client message
encryption, signing (sender authentication), and compression are again
feature negotiation problems, which I would really like to see some work on.
My two cents on this is that if we start with the posit that the client is a
resource, we could always expose client functionality (extension features)
through the resource description framework, RDF...

	A good question is: Patrick, if you're so keen on feature negotiation, why
aren't you working on it? My answer is: I'd like to see where Jer is on this
right now, and work with that if feasible.


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

	Sounds good to me. Credit goes to Michael Nygard for kicking it off;
anything that's good about JabberBeans is probably his fault and anything
that's bad is probably my fault.  ;)


Patrick