[infiniti at affinix.com: Re: libpsi port]

[Daniel Stone]

FWIW: Justin advocates the same solution as I do - use KExtendedSocket
(this is what I've always said), but he won't put it in the upstream
version of libpsi. Which is eminently sensible.

So, the solution is to only include our KDE-based stuff in *our* CVS
version of libpsi.

If anyone can see how this is advocating Neil's way of forcing the KDE
class stuff into upstream, as he insisted in a gloating private mail,
please point it out to me.

----- Forwarded message from Justin Karneges <infiniti at affinix.com> -----

Date: Mon, 24 Feb 2003 19:32:27 -0800
From: Justin Karneges <infiniti at affinix.com>
Subject: Re: libpsi port
To: Daniel Stone <dstone at kde.org>,
	Neil Stevens <neil at qualityassistant.com>

> > Would you be adverse to structuring it so that both sets of classes are
> > available in your releases?  Make it so that with the same library, PSI
> > could do:
> >
> > XMPP::Client client;
> > XMPP::ByteStream *stream = new XMPP::QtStream;
> > client.setStream(stream);
> >
> > But a KDE client could do:
> >
> > XMPP::Client client;
> > XMPP::ByteStream *stream = new XMPP::KDEStream;
> > client.setStream(stream);
> >
> > At least two KDE apps will use this library, but having only one version
> > of the library around would be nice.  Obviously the KDE classes could be
> > conditioned on a configure check of some sort.
>
> Bob the Angry Flower says: WRONG WRONG WRONG WHERE DID YOU LEARN THAT
> WRONG!!!
>
> Psi is a Qt app, and IMHO KDE stuff does *NOT* belong it. This is the
> wrong path. As Bob the Angry Flower says ...

Well, what Neil says is essentially how I plan for it to be used, except that 
I wouldn't include "KDEStream" or "QtStream" in the XMPP library.  The 
library will rely on ByteStream (which will be an external dependency not in 
the XMPP namespace, contrary to the libpsi CVS).  Subclasses of ByteStream 
would be used with XMPP, and "BSocket" is one such class I have written.

However, BSocket will not be part of the XMPP lib, and I suggest the same for 
any KDE networking code.

If I were to release an independent version of the XMPP library, I would make 
Cutestuff a dependency.  This is needed to provide ByteStream, but it would 
also supply the developer with BSocket so that he could use XMPP right away.

For KDE, I suggest following the same idea as I would for an independent 
library.  Pull what you need from Cutestuff (ie, bytestream.h and 
bytestream.cpp), and make a simple KDE class for networking (wrap 
KExtendedSocket or what have you).  Include everything necessary to use XMPP 
from within KDE.

You may still wish to #ifdef some code, say if you want to use KDE's SHA1 
implementation (does it have one?) instead of Cutestuff's.  In that case, 
just talk to me about it and I can add some conditions for referencing KDE 
code.

-Justin

----- End forwarded message -----

-- 
Daniel Stone 	     <daniel at raging.dropbear.id.au>             <dstone at kde.org>
Developer - http://kopete.kde.org, http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030225/e9d9f0ae/attachment.sig>