CenterIcq: defects list.

tetetest tetetest <[email protected]> Thu, 10 May 2007 12:37:40 +0400
Newsgroups gmane.network.centericq
Message-ID <[email protected]>
Hello all,

I have done some experiments with Centericq. Results are a bit 
frustrating.

First of all, I discovered that Centericq uses its own, very heavily 
modified version of libicq2000. This means that you cannot update 
libicq2000 in your system to fix some errors in Centericq - you have to 
wait until Centericq guy(s) get the issue fixed.

Ok, let's have a look at the modifications of libicq2000:

1. The library is compiled only as a static lib (funny, it has a double 
'lib' prefix: liblibicq2000.a). Cool. We don't have to install a shared 
*.so anywhere - the code just links with the binary executable. This 
makes Centericq monolithic. I like the idea (no irony).

2. One small, but very useful modification: a transparent wrapper is 
added to a 'connect' call on the library sockets. This enables proxy 
support (great! Original libicq2000 cannot work through proxies). I LOVE 
this modification. But, of course, there is a price for it: we have to 
compile an additional library that contains the wrapper code 
(libconnwrap.a). It's tiny, so there is no problem with that.

3. Here we come to the most doubtful part: the removal of libsigc++. In 
essence, libsigc++ is a library that allows libicq2000 to work with 
callbacks. Yes, this library is huge. Yes, libicq2000 makes use only of 
a tiny part of libsigc++'s functionality. Yes, the latest version of 
libsigc++ is not compatible with libicq2000. But look what has been 
done: libsigc++ was replaced by some other implementation called sigslot 
(Written by Sarah Thompson, Additions by Barnaby Gray - see file 
libicq2000-0.1/libicq2000/sigslot.h). I don't know whether this 
implementation is faster or more convenient, but it adds LOTS OF CODE. 
Compare:
- The latest libicq2000, statically linked with statically compiled 
libsigc++, is 2310172 bytes long in my system.
- The liblibicq2000.a from centericq's build directory is 9306644 bytes 
long (4 times larger!).
I wonder why could you not leave libsigc++? It can be compiled 
statically. Just add another lib to the distro - and get a smaller, more 
easily maintainable build.

4. Other very odd modification to libicq2000 is replacing the 
ContactList class with ContactTree. I can see the reason: you tried to 
add new functionality to libicq2000. But why did you not implement this 
feature separately, on top of the libicq2000 functionality?

So, to bottom it up: centericq uses very heavily modified libicq2000. 
This library is now quite far from the original code; it cannot be 
easily syncronized with original libicq2000.

Now, the defects list:

Libicq2000 (both original and modified for centericq) is very old. It 
uses messages in old format, and support for those messages is gradually 
dropped by ICQ servers. Here are the features that do not work because 
libicq2000 sends obsoleted messages:
- Full whitepages search. Just try to find anyone by sex, language 
and/or department - you will get zero results.
- Nickname, Firstname, Lastname search.
- Maybe some other search types (I had troubles searching by known UIN 
in centericq, but it works in original libicq2000).
- Auth acknowledgement/rejection messages do not work.
- You cannot update your information on server (i.e., cannot set a new 
Nickname) using libicq2000.

I think there are more issues (didn't have time to check it all).

Now, how do we fix the issues?

I can make a patch that fixes the "full whitepages search" bug. In fact, 
it's quite easy (I studied kopete's code for Oscar protocol, and found 
that new servers expect new SNAC type for this search). As for other 
fixes... Do we still need them? Or is centericq slowly dying?

Cheers.
_______________________________________________
Cicq mailing list
Cicq-xGejAJT2w6wWP6gT/[email protected]
http://mailman.linuxpl.org/mailman/listinfo/cicq
Questions? Check the FAQ first: http://centericq.de/faq/