[PATCH] SILC prpl ported to SILC Toolkit 1.1

[Pekka Riikonen]

On Sat, 2 Jun 2007, Mark Doliner wrote:

: I haven't looked at this in depth, but is it possible to keep our code 
: compatible with the old version of the SILC toolkit?  Maybe by only 
: enabling the new features if people are using the newer version of the 
: SILC toolkit?
: 
: I'm afraid that requiring a newer version makes more work for 
: distributions that package libpurple, because they'll either have to 
: upgrade silc or temporarily stop providing the silc prpl.
: 
There are quite a few changes in the Client Library API which would cause 
the code to be littered with #ifdef's if we want to preserve support for 
the Toolkit 1.0.  I did not do this, but certainly it is not impossible to 
do.

The changes are mainly in the SilcClientOperations structure which removes 
several callbacks that are now handled differently.  This would mean all 
connection, disconnection and connection error related callbacks would 
have to be partly duplicated.  Also some of the callbacks have changed so 
that their definition's would have to be #ifdefed.

All message sending routines would have to #ifdefed, as they have 
different arguments and different number of arguments.

All code leading to a nickname lookup functions (like 
silc_client_get_clients) would have to be ifdefed because Toolkit 1.0 
doesn't accept the lookup name to be a "formatted" nickname string but 1.1 
does.  1.1 accepts both formatted and unformatted so it would have to use 
unformatted and that means more code to get it into unformatted string, 
which are not done the same way in 1.0 and 1.1.

Also all client, channel and server resolving function callbacks have 
changed and would mean duplicating parts of the code.  Public key and 
private key handling, and digital signature computation and verification 
APIs have changed.  File transfer have some changes because the sessions 
terminate differently, due to some bugs in 1.0.

There are many other changes too.  I thought about preserving the support 
but it became clear that the code would be very hard to follow.  I'm not 
indifferent to the dilemma and certainly don't want to see distirbutions 
dropping SILC prpl.  I guess it's a matter of how cluttered you want the 
code to become.

I'd also like to know for how long this backwards support in practice 
would be used?  What are the issues why a distribution would not be able 
to upgrade to toolkit 1.1 with next pidgin release?  Tomorrow silc-client 
1.1 will come out requiring 1.1 Toolkit anyway and silc-server 1.1 will 
come out later this summer.  And every active SILC client developer I am 
aware of are already porting to 1.1.

	Pekka
________________________________________________________________________
 Pekka Riikonen                                 priikone at silcnet.org
 Secure Internet Live Conferencing (SILC)       http://silcnet.org/