[JDEV] Krufty Jabber Client

[arh14 at cornell.edu]

On Sun, 8 Aug 1999, Patrick McCuller wrote:

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

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

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

nononono...ugh

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

Client to client interactions should be virtually identical to client to 
server interactions (recieve message, send message).  No new protocol please.
The server just maintains client status and propigates events.

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

Waitasec...Jabber is not shoutcast ;p  Is this creeping featurism?  I 
don't think it is worth is to delay Jabber months to incorporate 
streaming media which other applications are specifically designed for 
and handle very well.  This could be a content plugin instead (instead of 
in the "core").  This leads back to MIME.  If you know the content, then 
"content plugins" can handle em.

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

Right. extension/plugin...this is what MIME is suited for..."gee, I don't 
know what application/gzip is, but GZIP-Plugin does, I'll pass it along".

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

ew...RDF? IMHO that is way out of scope for this problem...do we really 
need clients to support multiple interfaces/resources which need to be 
queried?  I believe that one, good interface will suffice for all clients.

> 	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.
> 
> 
[snip]

Aaron