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

[Daniel Stone]

FYI.

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

Date: Tue, 25 Feb 2003 00:36:50 -0800
From: Justin Karneges <justin at affinix.com>
Subject: Re: [infiniti at affinix.com: Re: libpsi port]
To: Daniel Stone <dstone at kde.org>

If you could forward this to the list it would be great.
--

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

This is not entirely true.  Let me try and break things down.

The new XMPP library will not use its own networking code for the actual XMPP 
connection.  This is to go along with the fact that XMPP is not tied to TCP, 
which is just one way to transport it.  The library will operate over 
anything using ByteStream as a base class.  However, and I just realized this 
later today, is that the library _will_ contain networking code for the 
purpose of P2P connections (ie, File Transfer).  In this case, perhaps 
substituting with KExtendedSocket would be in order.  Another area where KDE 
code could be reused is crypto.

Even so, most of this code for me will be in a separate library I have dubbed 
"Cutestuff".  If you wish to use the new XMPP library with maximum code 
reuse, your job will be to replace all Cutestuff calls.  As I stated in my 
previous message, I will accept patches for conditional (ie, #ifdef'd) KDE 
code, so that you guys can easily upgrade when I improve the library.  This 
has been my stance for quite a long time now, I just haven't received any 
such patches yet.

Note that I have not started on modifying the XMPP library, this is just what 
I have planned.  The goal is simply to abstract away the XMPP transport layer 
and move lots of non-XMPP code into Cutestuff.  Otherwise, I am quite pleased 
with the structure and function of 'libpsi' and the API will likely not 
change very much.

-Justin


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

-- 
Daniel Stone                                     <dstone at trinity.unimelb.edu.au>
Developer, Trinity College, University of Melbourne
-------------- 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/a7531da3/attachment.sig>