libim/tm/kim (was Use case for per-protocol icons)

[Casey Harkins]

Josh Williams wrote:
> libim (library instant messenger):
> Experimental virtual protocols, such as terminals and a global,
> non-standard libim-to-libim file transfer method. (Can you imagine how
> wickedly cool it would be to have ssh and telnet terminal contacts in
> your buddy list?)

You could likely do this with protocol plugins for libpurple without 
having to fork.

> kim (kde instant messenger):
> In contrast to tim, kim will have only one main window for the buddy
> list and chats (unless the user chooses otherwise). Both the chat and
> the buddy list can be expanded or collapsed as the user wishes in
> order to save screen space.

As has been mentioned previously, a KDE libpurple client would certainly 
be welcomed.

> Unlike Pidgin, however, I would like to write kim to allow the user to
> choose which backend he uses, so it would not matter whether he
> prefers libim or libpurple. While libim would have more toys,
> libpurple would probably be more stable and secure (unless the libim
> project gains momentum). (Note that I do not wish to limit the user to
> _only_ the libim and libpurple backends; there will be a standard
> plugin API to allow the user to choose backends.)

You might want to look at telepathy.freedesktop.org. There is a SoC 
project implementing a telepathy connection manager using libpurple and 
a prpl plugin for libpurple to use telepathy connection managers. If you 
did write a libim, you could make it a telepathy connection manager and 
base your clients on telepathy and get the pluggable backends for free.

> Again, if you would like to help in this project, feel free to send me
> an e-mail.

Good luck with your project. I hope you take the advise of many on this 
list and avoid forking libpurple if possible. Or, look into telepathy if 
that is closer to your needs.


-casey