Pidgin is implemented in the fairly typical way, libpurple provides the support for the network protocols and a ‘chunk’ of plugin crap for everybody. Pidgin and Finch provide graphical and textual user interfaces around it. I don’t think I really want to know more about the relationship plugins have with the purple library and their respective UIs then I already do. Although I’ve never used it, I reckon that InstantBird would be designed like Pidgin, but with a Mozilla Firefoxian XULRunner UI layer in place of the GTK/GNT UIs of Pidgin/Finch.
That kind of implementation for a program like Pidgin is basically Computer Science 101, using XULRunner may be considered CS 102. Pidgins approach to solving the problem is about as standard as putting butter on your toast in the morning. Early today, I was thinking about how I would implement an Instant Messenger program; let’s just say I’ve used many and hate them all :-P.
The first thing that can to mind is splitting the program in half: a multiplexing daemon and a chat client.
The daemon would take care of the per-protocol issues, likely using libpurple (as its so damn popular 8=) or a plugin architecture built around per-protocol libraries (libmsn, libgfire, etc). The client would provide the part of users actually see, and communicate with the daemon over network sockets to perform its task. You would launch the daemon and it would log you into the various networks, then you would launch the chat client and connect to the daemon. About 10 minutes later I figured it would likely be worth trying to implement the server daemon to chat client communication, by making the daemon expose its interface to the client as an XMPP server; instead of rolling my own protocol to do the same type of job. I am personally not partial to XMPPs functioning, but find it exceptionally useful in practice.
What side effects would my decision have?
A.) The daemon (your accounts logged in) could run on a different machine then your chat client (chat windows). This would make it trivial for example, to run the daemon on my file server and connect to it from my other computers – without logging out of AIM, MSN, blah blah. It would also be trivial to allow tunneling the two programs communication over an arbitrary program, like SSH, which would provide local-encryption of traffic between client and daemon 😉
B.) Because of the client / server design, it would be possible to access those IM networks from multiple locations at once, even if the protocol doesn’t support this. This is because the server daemon is logged in, not your chat client, hehe. Meaning that the daemon would have to implement the concept of multiple clients connected, which would be fairly easy (thinking of how this might be done if daemon-client commu was XMPP, really made me smile when I realized that XMPP supports something close enough to this).
C.) Because the client has no concept of a network protocol beyond what it needs to talk with the daemon (that does the real network leg work for various protocols), it has no physical connection with the implementation of code that does.
A and B would create an Instant Messenger program like Pidgin, that is to IM what TMux and GNU Screen are to terminals! Point C would just be awesome in my opinion. It would evade creating something like the UI related fields of PurplePluginInfo’s and make installation and maintenance more independent then any other IM program I’ve seen.
To me, the daemon+client thing it is just the most obvious way of doing the job…. lol. Ahh, I wish I had the time to write it!