Pidgin News

The application period for applying to Google Summer of Code opened on Monday and we’ve already received a number of applications. The application period closes next Friday, May 3rd. Just 8 days left—don’t wait, submit your application soon!

Google has accepted Pidgin into Google Summer of Code 2013. Woo-hoo! We’re looking forward to mentoring a few lucky students again this year.

For more information, read Google’s announcement, peruse our application template, and see our list of project ideas. The application period beings April 22nd—just two short weeks away!

We always encourage our users to brainstorm and share your ideas on improvements you would like to see in Pidgin, Finch, and libpurple. Feel free to share thoughts and ask questions on our devel mailing list.

So, Microsoft recently announced that they’ll terminate the Windows Live Messenger service in favor of Skype in early 2013.  We’ve been getting a number of questions about what this means for Pidgin.  Quite honestly, we don’t know.  At this point, all we know is that China will still be able to use Windows Live Messenger.  That leads us to believe that the servers providing MSNP service will remain active and maintained for some period of time after the announced shutdown, but it’s not clear whether or not that will be the case.  It’s also not clear if the servers supporting China’s continued use of WLM will be accessible to non-Chinese IP space.  Even further, it’s not clear if the recently-launched XMPP interface to the WLM network will remain functional.  We don’t support that yet though, as it requires some authentication magic we don’t implement.  Even if we implement support for the authentication this XMPP gateway requires, it could end up being a waste of time, as it could get shut down at any time, either before or after the rest of WLM.

And before anyone goes there, we can’t support Skype.  There is no documentation of the protocol available to us, nor is there code we can borrow from a cleanly reverse-engineered alternative implementation.  All that exists is SkypeKit, whose license agreement explicitly forbids its use in open-source software.  The license also forbids use in “server applications” which precludes doing something like wrapping a simple closed-source XMPP daemon around SkypeKit.  It is not currently possible to legally support Skype, so we won’t try.

The bottom line is we have no idea what the announcement means for Pidgin or any other alternative clients yet.  We’ll all just have to wait and see.

If you have had the pleasure of reading a great contribution to academics, be it any field – you could marvel at how systematically and sequentially authors write their work. Well, if you are after impressing the world – you better know how to trick-o-treat with words! I have been very fortunate to be part of a system and academic curriculum where meaningful and real-world impacting research took place. I have a very few academic publications to my name. I could easily count them on fingers, 3 if I remember correctly. But being a part of the academic community leaves an impression which cannot be replaced by any thing else. It’s the same thrill one feels when jumping off the cliff (for a bungee, ofcourse). I have wondered why, WHY do I keep getting these thrills to do some academic research again. I know, what I currently do is what I like but I keep getting attracted to the other side of the park – which theoretically (pun intended!) is GREEN.

The issue that I want to raise today, is how research happens in an environment where students doing their Bachelor’s or Master’s interact with their senior colleagues. To start off let’s look at how a Bachelor thinks of research. In his opinion, research is a way to glorify his path to success. A way to vent his thirst on something he finds meaty. The charm of doing what very few do. All this is good, simply because of the hundred’s of dead-end ways of spending his time — here he is destined to learn something useful. But he is no different from a “toad in a well”. His view of the BIG PICTURE is restricted. What matters to him is his short-sight towards quick-glory. Compare this to a Doctoral Student who would spend few years just learning about the domain he is about to rip apart — a bachelor student gets a few hours over the week assigned to him by his professor! Ofcourse, I am speaking this in context of IIT’s research fraternity.

The professor’s view of a bachelor’s student is very interesting. I am trying to anonymously quote one of the discussions I had regarding this with a very friendly department professor. He started off by expressing the obvious that Bachelor students at IIT are perhaps the best thing that might happen to this group of institutes. But the real research is not happening here. The reason being — lack of long term dedicated students. An good BTech might dedicate some 6 months to an year but then he’ll move on. What happens of the work he left behind, what about the continuity loss to the prof-in-charge? This is a motivating argument to considering the amount of effort put on part of our already-so-burdened professors. Well, I feel for them. They have had a lot to deal with — poor facilities, lack of good funding projects and the most essential – lack of competitive brilliance in their teams!

But how does a student feels when he gets a paper, some 12 pages of cribbing only a very few idiots in this world could understand, gets accepted! It’s enthralling. You feel as if you have been accepted as being one of the enlightened. I felt very delighted, on top of the world, cloud 9 or any-damn-cliche! I always wonder why that was, and one of the instantaneous reasons would be the audience. They consist of some really brilliant people known for their devotion towards excellence — and there you go, excellence is what makes it complete.

If you are one of those students, in your sophomore or around years of college, don’t think twice to accept such opportunities. Research is not about becoming the PhD nor does it involve kung-foo. It’s an adventure, sometimes tough(characterized by frustration) and sometimes enlightening(characterized by discovery). But it’s something that you would want to experience.

 

Best of luck!

Cheers

–S

Google Summer of Code is over, so there is a need for a little summary. Pidgin was accepted with four projects, three of them (this one too) succeeded. Gadu-Gadu related project changed a bit since it was accepted, but I’m still satisfied with progress done – you can judge it for yourself by reading this post. Some promised features weren’t completed yet, mainly because of need to make changes in libgadu. They will be done, but it must take time: discussion, libgadu implementation, libgadu release, updating libgadu in Pidgin, Pidgin protocol plugin implementation and finally pidgin release.

This project wasn’t only stripped down. There were improvements, which were not planned, but they came up to be really useful to bring better experience for Gadu-Gadu users. This is the point, where we got perks from 3.0.0 break – I was allowed to change anything I liked to in libpurple API. This is also a point, where other protocols gets benefits.

Proposal promises – reckoning

At first, I will compare actual state of work done with accepted project.

File transfer: I have succeeded with reverse engineering of newest GG11 protocol, even with successfully implemented example client, that sends a file. Unfortunately, one thing prevented me from implementing it in Pidgin: authorization method. To do a file transfer, I have to provide a hash, that is accessible only when user connects using newest session protocol. Libgadu doesn’t handle it yet. However, I plan to reverse engineer and implement it in the meantime, but it may take some time. On the other hand, there were a possibility to implement old file transfer protocol, but Gadu-Gadu service provider is dropping support for it, so it could be a waste of time.

Contact list synchronization: succeeded. It requires libgadu to be compiled with zlib.

Windows SSL support: Pidgin 2.x on windows doesn’t support GnuTLS, which is required by libgadu for encryption support. I had planned before, to implement encryption through Mozilla NSS for libgadu, but it turned out, that Pidgin 3.x will switch to GnuTLS. It seems, that SSL will be supported on Windows without any effort from my side.

Code refactoring: GG protocol plugin implementation was full of old, buggy and difficult to maintain code. Rewriting it from scratch was the easiest way to higher its quality. I have managed to rewrite half of its code by producing twice more than whole previous implementation was. On the occasion of code refactoring, a lot of bugs were fixed.

Voice chat support: failed. According to libgadu documentation, it was possible to talk with GG clients over SIP protocol. I wasn’t able to communicate this way now – it seems, that protocol has changed: new GG11 uses flash player based voice chat client.

SOCKS proxy support: work in progress. This one requires deep changes in libgadu, discussion isn’t finished yet.

Multiple gadu-gadu servers support: succeeded. Connection servers history is hold, so user is able to select one without searching for them on external websites.

Multi-login support: mostly done, without possibility to disconnect other sessions yet.

Better inline images support: succeeded.

Account management directly from Pidgin: succeeded, without option to restore lost password, because I haven’t had any idea to where it should be attached to.

Full avatars support: succeeded.

Setting public profile information: succeeded, unfortunately with not-so-recent GG10.5 protocol (for the same reason, like for file transfer).

Using public directory nickname for new contact’s alias: succeeded.

Full text formatting support: failed. This part of code have to be refactored. I haven’t reached here yet.

Closed tickets: #6263, #9463, #13739, #14305, #14649, #14776, #14951, #2188, #6918, #11693, #14012, #15132, #a11300, #a6595. Six more left: #343 (mostly done), #372 (waiting for libgadu), #5576 (also waiting for libgadu), #8945 (this code have to be refactored), #13584 (there is also need for code refactoring), #14366 (almost done).

Additional work done

Besides working on objectives set in project proposal, I have done some work more, mostly for libpurple API.

The most important thing done, was reverse engineering of GG11 protocol. This wasn’t complete, but it’s a good start for further work. Moving to new protocol have to be done, to fully support features like file transfer or public directory. Additional gain from this task was creating Gadu-Gadu protocol dissector for Wireshark.

Pidgin’s account setup dialog was significantly improved for protocols with automatically assigned user identifiers.

Username validation feature will affect user experience with eliminating mistakes when adding buddies or setting up new account.

Similiar feature introduced was validation for dialogs created with Request API. Before, it was only possible to validate entered data after closing a dialog, now we can do this just after filling in certain field.

Introducing GG connection servers history wouldn’t be possible without an option to attach hint list for text fields in account setup dialog. Of course, other protocols (like IRC) will get benefits from it.

There are also some discussions in progress, described in my previous post.

Source code

Code implemented during GSoC is available through hg repositories, or directly, in packages prepared below:

• set of all committed patches;
• all changes gathered into one big patch (only these directly made in GG prpl);
• whole GG prpl source code (files rewritten entirely by me, has note Rewritten from scratch during Google Summer of Code 2012);
• dissector plugin source code (not included in any above).

What’s next?

As you could notice, the biggest issue, which disallowed me to do well many features, was lack of GG11 protocol support. Reverse-engineering and implementing it in libgadu is the main goal for me after GSoC.

When I do above point, I will finally introduce file transfer support. It’s one of the most desired features, requested by users from the beginning of GG protocol plugin.

Next task to do will be refactoring of remaining code and completing documentation.

Yesterday, we had firm pencils down date. That means, this is the last set of updates within this year’s GSoC. But not the last one for Gadu-Gadu prpl – I will continue my work in the meantime, to make Pidgin up-to-date with current GG service features.

The biggest feature done this week was browsing and editing public directory with GG10.5 protocol. Unfortunately, just like some other features, there is no possibility to use current, GG11 protocol, because this service requires IMToken value (not accessible in current libgadu) to authenticate. Whole public directory related code was rewritten from scratch, so bugs (#14951) present with the old code should not exists now. This approach allowed to implement new feature: using buddy public alias for new contacts added to buddy list (#2188). To try it out, just add some buddy without filling alias field. There is now also possible to set your own profile information (#6918). On the occasion of moving to newer protocol, OAuth support was extended, so it’s possible now to support more services.

Another large code refactoring (but this one without so many new features) was new implementation of status handling. Some bugs were fixed: there were problems with long status messages, or these which contained UTF-8 characters.

Libpurple API wasn’t forgotten this time: there is now possibility to provide a list of hints for text fields in protocol setup dialog. This may be used for example in protocols, which allows to type in custom character encoding (like IRC).

With this new libpurple extension there were now also possible to implement new GG related feature: servers history (#11693). All successfully connected servers are added to global history and displayed as hints in account setup dialog.

There are still some discussions in progress:

• message delivery notifications: none of the main Pidgin devs answered, but probably because it just needs to be implemented;
• custom username labels for certain protocols: discussion stuck;
• new http support, based on library like curl or libsoup: there is a need to select one;
• new status – chatty: requires more work than it looks like;
• custom connection functions for libgadu (this is needed for proxy support): implementation-related discussion paused for a while;
• getting buddy public alias before adding him to buddy list: no-one answered yet.

In next few days I plan to publish whole GSoC summary.

Libpurple is a library with a very stable API. That’s convenient for users, because most of old plugins works with new versions of Pidgin, but it’s also restrictive. That means, Pidgin cannot evolve as much as other messengers to support well new protocol features.. Fortunately, there is Pidgin/Libpurple 3.0.0 coming, so we may change what we want here.

Indeed, recently I was working on libpurple API in areas, where Gadu-Gadu had too little air. For example, I have implemented validation of usernames: GG service uses only numerical identifiers, while Pidgin allowed to type in anything. Now, dialogs like buddy adding or account setup won’t accept invalid GG numbers.

I’ve also implemented setting of own avatars, so avatar support is complete now. Unfortunately, it uses old protocol, because new, GG11 protocol for avatars requires (just like file transfer) IMToken value, which isn’t accessible for current libgadu.

Among cosmetic fixes, handling of users, that blocks us is finally done well. Now it displays denied icon on the side of buddy alias. Previously, it was indicated by invisible status. There are also warnings, when we try to send a message to such person.

Another new libpurple feature was validation for dialogs created with Request API. Now, new IM dialog won’t allow to type in invalid username, Gadu-Gadu account registration dialog won’t flicker when filled in improperly.

Initial multilogon support is already implemented. Messages are synchronized between sessions and issues related to own status are fixed (#14776). There is still need for possibility to view and eventually close other sesions and (optional) status synchronization.

Code related to own status was refactored, so few bugs related to it was fixed.

Hi,

As part of a (un)timely dose of SoC updates, the Statscollector project is moving towards a mini milestone. With the UI part now consolidated and the client having all functionality of a mature plugin, we might have an official statscollector and display UI very soon . Currently the UI is hosted (with some test data) here. It may be down once in a while, and will  change once we go live, but for the enthusiastic who wants to  give inputs — you’re most welcome .

The plugin is now equipped with the following functionalities:

* Ask the user for the first time, “if he wants to submit stats”.

* Have the functionality to “Ask later” and also to change his preference using the prefs box

I have used the request API from pidgin, which means that the above functionality should span across Pidgin/Finch/(adium?) or whatever implements libpurple for their XMPP clients — great huh?

On the server side, the UI is pepped up to handle the following stats:

* Account/Plugin/UI information/Version info

* OS/Architecture/Bitness

It’s pretty much all about the highchartsjs API which makes the UI look apart .

Cheers!

Sanket

I have successfully managed to reverse-engineer a new file transfer protocol for GG11. Good news is, that I implemented my own client, able to send a file. Bad news is, that it requires a token, which is send by Gadu-Gadu service after successfully logging in using GG11 protocol.

That means, Pidgin (and other clients, like Kadu) will be able to support new file transfer method just after introducing GG11 protocol support for libgadu. On the other hand, old file transfer protocol implementation for Pidgin have questionable value, because original Gadu-Gadu client seems to be in middle of dropping support for it.

General information

File transfer in GG11 is based mostly on HTTP queries. Original client uses https protocol, but unencrypted connections are supported too. To begin a transfer, we need IMToken value, which is sent by Gadu-Gadu service just after successfully logging in using GG11 protocol (GG10.5 doesn’t get such packet). Token is valid until closing GG11 connection.

Client, who wants to send file creates a “ticket”, which is file transfer identifier. After accepting it by the receiving side, file is uploaded to GG drive (service like Dropbox or Google Drive), to special folder (not accessible for end-user). Then, receiving side downloads this file from server.

Protocol doesn’t provide information about downloading progress. That means, after file upload, user is notified about successful file transfer.

Example PHP script, which sends a file, requires only the token mentioned before. This must be sniffed (ie. using Wireshark tool) from original GG11 client session. While transferring a file, original session must not be closed.

Sending a file

Receiving side have to use client compatible with GG11. Protocol communication is described below. Details about sending and receiving mentioned fields are contained in example implementation.

#1 we log in using GG11 protocol.

#2 we get a packet with IMToken (packet id: 0x8C)

struct gg_imtoken
{
	char magic; /* 0x0A */
	char token_len;
	char token[token_len];
}

#3 authorize (once per session), sending PUT https://drive.mpa.gg.pl/signin request. Provide:

• own GG number;
• received IMToken;
• client id (?) – it’s probably constant for certain client version, it may be anything (it’s not validated);
• computer information (hostname, system, client version, client type – desktop).

Session cookie and security_token (additional protection, constant during a session) is send in response.

#4 offer a file transfer. Original client does it before authorization and gets 401 error. Send PUT https://drive.mpa.gg.pl/send_ticket request, providing:

• receiver GG number;
• file name and size;
• security_token and session cookie.

We get json struct, SEND_TICKET_STATUS (temporary name) with fields:

• id: transfer identifier (ticket id);
• sender, recipient: GG numbers for sender and recipient;
• file_name, file_size: name and size of file;
• send_progress (float): file uploading progress – a number between 0 and 1.0;
• ack_status: what was receiver decision – possible values are unknown, rejected, allowed;
• send_mode: (?) always normal;
• send_status: status of upload – possible values are in_progress, completed.

#5 we can now ask for file transfer status, by GET https://drive.mpa.gg.pl/send_ticket/[ticket_id] request. Provide security_token and session cookie, receive SEND_TICKET_STATUS struct.

#6 if receiver accepts the file, we may upload it to GG drive with PUT https://drive.mpa.gg.pl/me/file/outbox/[ticket_id]%2C[file name] request. Provide security_token, session cookie, type of sent data (file) and file content. File name should be encoded with function like php’s rawurlencode. Original client have issues with receiving files with filenames containing non-alphanumeric characters. This affects files sent by original client too.

Status notifications

Less detailed information about transfer status are sent in original GG11 session too. That means, there is a possibility not to use https://drive.mpa.gg.pl/send_ticket/[...] requests at all. It’s done with packets described below (names are temporary).

Received notifications are common for various services from new protocol (among others, there are notifications for GG drive too):

struct gg_mpa_notify /* ID: 0x84 */
{
    char magic1[3]; /* 08 02 10 */
    uint8_t seq;
    char magic2; /* 1a */
    uint8_t data_len;
    char magic3; /* 01, not always present */
    char data[data_len];
    uint8_t ntype_len;
    char ntype[ntype_len];
    char magic4[10];
}

After receiving any of gg_mpa_notify packets, we have to reply with its sequence number:

struct gg_mpa_ack /* ID: 0x86 */
{
    char magic1[3]; /* 08 06 10 */
    uint8_t seq;
    char magic2[2]; /* 18 01 */
}

Possible types (ntype field) of json packets, related to file transfer:

• edisc/send_ticket_changed: simplified version of SEND_TICKET_STATUS, containing fields id, ack_status, send_status;
• edisc/scope_files_changed: sent after uploading file to GG drive.

Possible sequence of packets for proper transfer:

1. send_ticket_changed [ack_status: unknown, send_status: in_progress]
2. send_ticket_changed [ack_status: allowed, send_status: in_progress]
3. send_ticket_changed [ack_status: allowed, send_status: completed]
4. scope_files_changed

Summary

File transfer protocol is revealed enough for implementing it (see example script). Unfortunately, it doesn’t seems to be possible to get IMToken value using old GG protocol, supported by libgadu. That means, there is a need for additional effort in enabling libgadu support for whole new protocol. Positive aspect of such changes will be getting much more reliable method of file transfer – that doesn’t depend on client visibility behind NAT.

Recently, I’ve been working on a new feature: contact list synchronization (#9463). Gadu-Gadu service introduced support for it while ago. It works similarly as for xmpp protocol. Changes were extensive, so it may not work perfectly yet, but I’ve done my best to do it well. Although, if someone wants to help with testing (Linux machines only at this moment), don’t bother to ask me for sources. Or – even better – check out them directly from repository. However, I may not be able to access Internet in following week, so the second option would be better.

Buddy avatars handling was reimplemented. Now, it consumes much less network traffic and doesn’t freeze user interface. Instant update of avatars works again now (#13739). Reducing network traffic fixes issue of crashing on systems with gnome desktop (#14305).

Another new feature was done: username validation (#14649). Changes were done in pidgin and libpurple, not Gadu-Gadu protocol plugin, but the last one gets benefits from it. Now, there is no possibility to type in invalid (non-numeric, or even with just a space before or after) GG number in account setup and buddy adding dialogs.

Now, I’m working on:

• validation in dialogs from request API (new account registration, password change dialogs);
• message delivery notifications (discussion started);
• change misleading “username” labels to “GG number” for Gadu-Gadu protocol (discussion stuck);
• proxy support (discussion also stuck).

This time I have mostly been doing code refactoring, resulting in bugfixes and following improvements.

After 3.x.x API changes, receiving of inline images was broken, it’s fixed now. There is one more issue related with new API: sent inline images are not displayed in conversation window, but it’s not Gadu-Gadu protocol plugin issue.

New feature related to inline images was introduced: notification about delivery status of sent pictures.

Account registration feature was fixed and got improved usability. Improperly filled form notifies about invalidity and let user to fix it, instead of closing and dropping entered data.

Password change dialog also was reimplemented and refreshed.

Both of above were improved by new implementation of http requests handling. Now there is an option to show cancelable notification of running request.

There were fixes for GTK Pidgin user interface too (indirectly related to GG protocol plugin). Most important was better support for protocols with automatically assigned user identifiers, by fixing registration dialog for them.

Now I am still working on proxy support (discussion ongoing, proof-of-concept implementation done), username validation (also at discussion stage) and improving avatars support.

New DNS resolver for libgadu is already done. This effects in stability (especially, under Windows: #6263) and some code cleanup (win32 related code is no longer needed).

Also, now our libgadu fork have just one-line difference against upstream (#343). At least, it will be one line after upgrading to 1.12.0, because now we have some patches plucked from upstream trunk.

The biggest progress was made at reverse engineering of new Gadu-Gadu protocol. Newest official Gadu-Gadu client (11.0) doesn’t allow to make unencrypted connections, so protocol analyzing seemed to be impossible. Fortunately, I have managed to bypass this restriction and now everything goes as plaintext.

The next step was creating GG protocol dissector plugin for wireshark – it requires some effort, but it makes following work much easier. At this point, only most important packets are dissected.

Two steps listed above enabled me to make the third one: making some findings about new GG10.5/11 protocol. I will publish them later at libgadu protocol description site – it’s polish only, but my dissector plugin will also contain these information.

Now I’m in the middle of providing proxy support, but it requires deep changes in libgadu library, so I have to discuss it with libgadu team.

Hi all,

It’s a proud moment to actually see your baby fly . If you have been following the other posts on this category, you might have heard me saying a lot of stuff about how the server and client sides will be interacting to show the final stats. The hour of truth is here and I have finally completed a bare-bones version of statistics website. Before I blabber about it’s salient features go have a loot at it!

As I had discussed currently it has basic statistics (drawn from a rather small sample of a few dev’s sending there share of information). Currently you can see, the type of Operating System, the architecture type, bitness of the application/operating system and other purple specific statistics. I have used highcharts and it has proved to be *quite* an impeccable JS plotting library. It gives neat and smooth transitions. You should check out Operating System information where clicking on either “Windows” or “Mac” drills you down into another chart, without having to reload the page .

The tough part, ofcourse is testing the server. I will be bottom posting a few code links where you can find all the stuff I have done. I am currently trying to tract developers to use my plugin and help me in testing the server components, as well as spanning different variety of machines. I will split this section for windows, mac and linux/unix/POSIX users separately.

WINDOWS

If you are using windows, I already have a compiled DLL for download. You can help yourself with the link here. To enable the plugin copy the plugin in your .purple/plugins/ directory and enable it using Tools->Plugins->Statscollector.

The version of this plugin is compiled with 2.10.4 which is the latest release currently on pidgin.im. If you are a energetic and tedious [;-)] tester or wish to compile on a different release (2.10.5devel) hold your horses till the “From Source” section.

LINUX

This section (should) hold for all flavors of linux as long as the version is compatible. If it does not work, then most probably you need to compile from source . In linux you require a .so file to work with plugins. I have compiled quite a few .so files with linux and will be providing you with versions of 2.10.4, 2.10.5devel and 3.0.0 (current im.pidgin.pidgin). Though IMO you should check your pidgin version and as 2.10.4 is the current release, try to test the plugin with that. I am unsure _if_ these plugins should crash pidgin. If they do, please compile your code from source.

32 bit

2.10.4 — http://dl.dropbox.com/u/11564582/statscollector-2.10.4.so

2.10.5devel – http://dl.dropbox.com/u/11564582/statscollector-2.x.y.so

3.0.0 – http://dl.dropbox.com/u/11564582/statscollector-2.10.4.sho

I currently don’t have access to a 64 bit Operating System running linux. So if you have indeed installed a 64 bit pidgin, might as well build from source

MAC

Mac is much more like a Linux Machine and building code should be equally easy if you are working on a development scratch-pad. That said, I don’t have binaries to ship out for Mac either !

SOURCE

Building from source is perhaps the most reliable (and easy for me to maintain) way to do things! The source for the plugin could be found in the mtn repositories here. Check out the head and look for the file, libpurple/plugins/statscollector.c. You can make the plugin by using tips here!

If you do decide to install my plugin and have a go at it, let a comment so that I can fix any bugs/ask for feedback.

Cheers!

I have started my work on this year’s GSoC by some cleaning up. My work is available under im.pidgin.soc.2012.gg branch.

Making trunk usable: default theme wasn’t ready to use, so I’ve made it as close to legacy one, as possible (in reasonable amount of time). It still needs work, but at least it’s comfortable (#15129).

Tickets cleanup: all gadu-gadu related tickets were assigned to me, I done some investigation for some of them. Closed tickets by type:

• wontfix: #14012
• duplicate: #15132
• transferred: #14347
• verified as fixed before: #a11300, #a6595

Updated libgadu to 1.11.1: by the way, I’ve reduced some differences with upstream (#343). Also, some internal libgadu configuration polishing was done.

Now I’m working on DNS resolver for libgadu, that uses libpurple methods.

Howdy all,

In the continuing series of posts, I will today highlight another aspect of GSoC project. This time we’ll take a look at the server components, and some rational as to why these are chosen. If you have been following the previous posts, you’d know that I have been actively working on collecting whatever the system can provide me with information regarding the activity on your pidgin and/or the information about OS/hardware features. Pidgin devs find it useful to know where to concentrate their focus while developing protocols et. al for pidgin.

The hardest part in stats collection apparently turned out to be CPU info, as it is heavily OS/Architecture dependent and hence a lot of #ifdef _some_os_ stuff etc. For now I have been able to stabilize it to _some_ extent. Well development on that end will continue as we speak .

This post considers some of the server related issues. So the technologies that I’ll be working with for the server components are DJango for serving the logic on top of MySQL (anyhow DJango very nicely abstracts DB connections using the classical MVC architecture). As the task involves a lot of graphing, Eion has suggested me to use this awesome JS native library called, “Highcharts” which apparently is very savvy. I am currently figuring out a way to meld Django with Highcharts’ JSON objects cleanly.

Let’s wait and watch for some magic to happen soon !

Hi all,

It has been an exciting ride till now, and mostly discovering new stuff. I’ll discuss what has been the plan all this week and what all I have been able to achieve, including the most amazing learning experiences with pidgin .

The task is to collect useful statistics which could help libpurple/pidgin developers about what should be developed in which platform. We started with boiling down the statistics to the following categories and sub-categories.

* cpuinfo

* Protocol Plugins

* User plugins (gtk, core and others controlled by users)

* UI’s used (pidgin/gtk, finch/ncurses, adium, nullclient?)

You might be interested in how the final obtained output shall look for a Linux box running x86 architecture and Pidgin. Here’s a pastie view of it: http://pastebin.com/3sVFFd4a

As you could follow, I have used XML to story the contents (simply because XML is a inherent component when dealing with protocols and extensively used across various IM platforms). There is a lot of meat in the XML stats collection taking place — starting from CPUinfo right down to UI info and accounts, plugins etc.

I started off with writing components which were easier to do, and by easy I mean those which can be done on multiple platforms without trouble. It is my experience and lot other coders shall believe so, that cross-platform stuff can be REALLY nagging. It’s the same old store, IE vs the rest of world. Accounts, plugins and other libpurple specific information was hence easy to grab.

The tough part and the part in which I spent the better half of my time, was collecting CPUinfo. The various components of CPUinfo we are dealing with are:

* Architecture of the hardware

* Whether the application is 32/64 bit

* Whether the OS running the application is 32/64 bit

* OS/kernel description and version (in case of Mac and Windows)

The task is complicated by reasons obvious, we need a lot of native code and hence need to write separate sections for various OSes. We demarcated the OSes into the following categories

* Windows

* Mac/POSIX

* Linux/POSIX

* POSIX

So we could use absolutely separate code for Windows but mix and match code for the other boxes. I was surprised with the power POSIX compliance gives to OSes. Specially when it comes to knowing what hardware is really being run! Just for a small demo, you could try “uname -a” to know exactly what kind of hardware and kernel (to the extent of Linux kernel version and Flavor) being run. It was really a life saver because there’s *no* other easy way to do this.

The biggest hurdle till now has been determining bitness of application vs OS. This is necessary because there’s a big current question, do we completely switch to 64 architectures or there are lots of people who could not afford such a switch. Infact currently pidgin ports *only* for 32 bit windows applications, even when windows support 64 bit applications. The trouble again here is that you cannot use simple checks. Consider for example I did, sizeof(int *) to detect what is the Bitness, it’ll fail in case a 32 bit application is running on top of 64 bit OS. We had to come up with rather hacky idea of using “uname -m” in case of POSIX compliant OS and something called, “IsWow64Processs” in case of Windows to determine if an application is running on a 64 bit OS. I would remind here that architecture could *still* be different. Eg, if a 32 bit application is running on a 32 bit OS but the hardware supports 64 bit (say x86_64).

All in all, I learnt a lot about computer architectures and bitness and how they really fit into current scenarios. I also learnt a lot about writing #os-specific code . I am amazed at the amount of work I have been able to complete within few days of code-period and it looks like it’ll be a great summer of code ahead

Hi all,

Looks like this summer is going to be one dusty ride. I have been selected for the Google Summer of Code program, 2012 with Pidgin. Firstly my proposal is public. You are welcome to have a shot at it. I will be working on “Pidgin stats collection” and Eion will be helping me out with the project.

 

For those who are not aware of what Google Summer of Code entails. It’s a summer long coding program where students (and students only) are allowed to write proposals for any projects they might wish to pursue to various organizations. The organizations then choose students on requirement and quality of proposal basis. GSoC has been successfully running for over “5″ years now. The pay is nice (~ $5000) for a summer spanning 3 months.

 

I have been trying for GSoC for 4 years now, and this is my second success. So basically it’s pretty stiff to compete here! Coming to my project, I will be working on providing Pidgin with a usage-stats collecting framework. Pidgin being a multi-protocol client – has a lot of diversity and it’s generally useful to know what is being used a lot and what is used only scanty. Well, it’s a famous software engineering law that 10% of the software features are used 95% of times. Then better know them . I will be working on the lines similar to Sparkle, which is a stats collation interface for Adium.

 

It sounds a very interesting summer, and the project has a very largescale impact across Pidgin! The most interesting part being, as soon my plugin goes live – it starts collecting information. It’s always very exciting to see you baby fly . I have decided to write a regular blog in this space regarding my SoC progress.

 

Cheers

–Sanket

We’re pleased to announce that we’ve accepted four students for this year’s Summer of Code!

• Gadu-Gadu PRPL improvements by Tomasz Wasilczyk, mentored by Ethan Blanton
• Plugin website by Nikhil Bafna, mentored by Kevin Stange
• Usage stats collection by Sanket Agarwal, mentored by Eion Robb
• libpurple on Android by Michael Zangl, mentored by Mark Doliner

It’s always difficult to narrow down so many great applications into just a handful, and we want to thank everyone who applied. The coding period runs from May 21 through August 24. If you want to follow the progress of the four students, they’ll be providing periodic status updates to our devel mailing list throughout the summer.

Read Google’s official announcement here.

Libpurple was accepted in the Google Summer of Code  this year 2012.

I urge every student reading this to apply for any of the projects accepted and if you like, apply to Libpurple.

We have a set of proposed ideas but you are encouraged to bring your own ideas since they will be fresher and will not compete with other people over the same project.

You can find libpurple's application page at Pidgin, Finch and libpurple.

Good news, everyone! Google has accepted the Pidgin project‘s application to be a mentoring organization in this year’s Google Summer of Code. If you love programming and are looking for a chance to help an open source project, look no further.

How much can you accomplish in a single summer? Quite a lot. To give you an idea, here’s a list of some of our heftier projects of past years:

• SSL certificate verification and management
• Voice and video chat for XMPP
• The Bonjour protocol plugin
• The MySpace protocol plugin
• The SIMPLE protocol plugin
• Finch (command-line based IM client based on libpurple)

Details

• Get inspired by our ideas list. But don’t limit yourself to those ideas—we love when students propose their own projects.
• The application period starts March 26 and ends April 6th (full timeline)
• Once the application period opens, apply here
• We’re guessing we’ll request slots for 3 students this year.
• If IM isn’t your thing but you still want to participate, check out the list of other great organizations