Friday, November 27, 2009

My summer of code journey [part4]

The final evaluation!


Assuming that i was done with my history plugin, i told my mentor to review it, and also mailed the kopete-devel community so that if there are any developers with some spare time can review it as well, and went to prepare for my exams. I tried to make sure that during my exams that i stay in touch with my mentor and and project doesn't suffer because of it.
I got a reply from Oliver Goffart(author of the history plugin of kopete) stating that, 1) i have used lots of kdebugs, 2) my error checking was not proper 3) and most of the jobs i had used were synchronous job->exec() and it would be a good idea to redesign the plugin and use asynchronous jobs where ever possible.
Later that day krake also told me about his experience that he had lots of crashes while he was writing a plugin because of job->exec() and it is always a good idea to use asynchronous jobs, So i added a new todo in my list which was to make all jobs asynchronous. This job turned out to me more than what i had imagined. The history plugin uses QDomDocument and every method in there had sequential execution so i had to split a method in two parts(some method like readMessage into 4-5 parts) and introduce new variable, make them member of class so that they can be used in other parts of methods as well, overall it was very hard for me to change all akonadi related things into asynchronous jobs. The toughest thing i faced in my Google summer of code. 
The design of the plugin is something like this. Kopete has a messageHandler chain, so whenever a new message arrives, the messages flows through the message handler chain, so when history plugins message handler method gets invoked, the history plugin object creates a historylogger object. Two important functions of historylogger are the appendMessages and readMessages. When a new message arrives and the appendmessage method is called which saves that chat into akonadi. In the constructor of the HistoryPlugin we also connect a slot to slotViewCreated so whenever a new windows is created the readMessage method is called which reads a specified number of lines from the chat history and appends it to your chat windows.
So basically all the tough work was about making the readMessages and appendMessages asynchronous.

That took me some 20 days! :-( I was almost like doing everything again. 
But i got it working somehow! :) and trust me it was a nightmare. But the good thing was that I had my holidays and i was able to devote all time to it! :-)
After doing with my history plugin, I started with my telepathyWatcher application. The telepathy watcher is an Telepathy client application(basically an telepathy observer) that logs all the text chats that you do using the Telepahy Protocol into Akonadi, using the same collections that are used by kopete.
I cleared my final evaluation, but I am not satisfied with the history plugin. I want to make the kopete history plugin better in terms of searching through logs, and give it a better UI and looks.

If you are interested in knowing more about telepathy you can find a good tutorial about telepathy here http://people.collabora.co.uk/~danni/telepathy-book/index.html
I will blog about the Telepathy-Watcher later, let me first put forward some of my confusions.
1)When kopete starts, I need to fetch collections from the akonadi, so that they can be made available to plugin.
At the moment when the plugins starts, i do a fetch job that fetches all the collections from Akonadi server. 
--> what pings me is that, I am fetching collection everytime kopete starts. No doubt it works but Is this the right approach??
2)When the plugin initializes, a good idea is to fetchItem with headers, so that in order to get information about a particular contact, we dont need to fetch items from akonadi. This looks like a good approach to me. 
But my doubt is, i have some 150 people in my contact list(with just 1 email id) and i dont talk to all of them everytime i start kopete, and I assume many all around the globe at one point of time, use more than one Account to log into kopete, so suppose they have 4 accounts, then i will be fetching some 500(approximated) item Headers from Akonadi. Will that be okay ???
Or a better idea can be something like, as soon as they come online i fetch their item headers?

3) Will it be better that kopete and the kopete-akonadi-history resource share a config, so that it improves performance?


Thursday, November 26, 2009

My summer of code journey [part3]

The Communication Bonding period and phase before the first evaluation!


With the results out :-) and my proposal being selected, all i could do was be happy!! :P I was delighted, but i was also a bit nervous. As a newbie with an ambition to finish everything i have promised in my proposal, what lay ahead was a mountain of a task!

It took me some time start with the development as somewhere during the time the results got out, i was experimenting with my linux and i have absolutely no idea what i did that led to breaking of my hard drive. That meant getting a new hard drive, installing linux, then downloading and building kde from source. 
Initially i coudnt understand what i was doing with my .bashrc file, the environment variables etc etc, i was just doing everything advised, reading them again and again trying to understand. My efforts paid off finally, now i understand many things that are in there :P 

Being a student of VTU ( A university in Indian)  I realized that Google summer of code will not be easy, because of the vtu exam time table, and their instinctive ability that they can shift, postpone and exam anytime they wish, i knew that i will have need to have a good time schedule with proper deadlines. 
Consider this

Apr 20th – May 22rd --- Community Bonding period
May 23rd – July 6th  --- Coding begins
And the initial dates of my exams were on June 16th – June 26th which got postponed to 22 to 5th july i guess.
July 7th – July 13th [7days] --- Midterm evaluation.
July 14th – Aug 10th --- Second phase of coding.

As you can see, I had my exams right in between the coding period, That really sucks you know?!!
I was lucky to have a good mentor George Goldberg and Kevin Krammer(you can call as my co-mentor) to guide me through. If you havent taken a look at my proposal, and reading my blogs related to Gsoc! maybe its time you should see it. http://docs.google.com/Doc?id=dg9f3fwb_4fdg7mpfh
The first thing in the project was to start with the I/O part and then start with telepathy watcher. But my mentor was quick to suggest me that instead of telepathy watcher i should start with the Kopete History plugin so that when i reach the telepathy watcher i will better understand things. True indeed!
I remember an interesting conversation i had with my mentor. These are the few lines that i know honestly that changed the way i work. Its not that i had never heard/read them before but this was certainly the first time that i really put it in execution and i am still doing it. At the first discussion about my project after the results were out, he asked me what my plans were and how was i going to do them, and i described some things to him(as at the beginning nothing was clear).
When i mentioned that these are the things that i am going to start with as soon as the coding period starts he said, " Why wait for the coding period to begin?, You have already done so much community boding lets start coding it". I was a little taken aback, and i said, "Right now??" and then he replied "Why not!?". 
The impact of this Why not is such that today when i hear a good idea from my friend or somebody, and i see the light in their eyes and the zeal to work on it, i try to encourage them to start working right now, and if by mistake they ask me back right now, then you know what i tell them! :P

So i started with the kopete's history plugin. I put in lots of kDebug() to find out how the control is flowing, and what functions are getting called in different scenario's to understand how the the history plugin was working, then i put it all in a flowchart( on a chart paper) to understand better how things were working.

In order to work in accordance with Akonadi, we need to have an akonadi resource and A serializer. 
When the Client application accesses akonadi, the Akonadi server then uses the resource to get that job done. for example If you need to create a collection, we will simple use the Akonadi::CollectionCreateJob, the cilents job is done. Now its the job of Akonadi to take care of the collection, where and how to create it. In order to handle that, Akonadi Server uses the resource. A resource is an akonadi agent that takes care of it.
I already had some sample codes which i had done for the proposal, so i started with the history class, finished that, then moved on to the resource. One problem i had was to figure out that, when you create collection, and want to create child collections for that, then the mime type of the parent collection should be inode/directory.

Some things that really gave me the trouble during writing the resource was the use of
changeRecorder()->itemFetchScope().fetchFullPayload();
changeRecorder()->fetchCollection( true );
I had not used them initially in the constructor and that gave me nightmares for some day, which was eventually solved then Vkrause told me to add the fetchCollection(true) aah!! :).
The first thing was to make the logger plugin save the chats in Akonadi instead of files. In order to make that possible i decided to use Akonadi jobs.
Akonadi works in terms of Collections and Items. A collection in akonadi can be thought same as a folder, and the Items as files.
So what i did was,i replaced the code which were saving the chats in fiiles with Akonadi::CollectionCreateJob, and Akonadi::ItemCreateJob and Akonadi::ItemModifyJob.

By this time, i remember it was time for me to start preparing for my exams, so it was around  13-14th june.
So in the time between April 25th - june 15 ( approximately 5+30+15=50 days, certainly took some time :P)
i was ready with
1) history class
2) I/O Api's (read history from xml file, write history to xml file)
3) the resource
4) the serializer
5) the edited history plugin. ( but i did make a mistake in this, i spent most of the time correcting it in the second phase of coding)

I asked my mentor to do a review of my work as, because As soon as my exams will end, i will be facing my first evaluation.
If you trust me, its tough doing Gsoc and being a vtu students( or having exams in between) *But its not impossible* 
As somebody once said
अगर लोहा हो तो गल जाओगे, अगर सोना हो तो तप कर निकल जाओगे!
So it will be basically a test of your character!

Monday, November 23, 2009

My summer of code Journey. [part 2]

Between application phase and Community bonding phase
 

There are bascically 4 phases in summer of code,
1) the application phase
2) the Community Bonding phase
3) coding before first evaluation
4) coding before final evaluation


As I have already blogged something about my application phase, lets start with the time in between the application phase and the community bonding phase. As mentioned earlier, I at first started with 3 ideas for Gsoc, but as the responce i got from Kde communiuty and my mentoer was very quick, i started to pay more attention to it. 
I come from a place in India, where the use of linux is not that wide spread. Here linux is like "Linux! What Linux??!!" Dont ask me, recently what happened , i was part of a infosys compus connect program, where we had to execute some program online (just like codechef and topcoder) and...it wasen't opening in firefox(as i was using linux) so i took online help and asked them why isnt it working, and they told me try it on "IE" or switch to another system. Anyway Lets come back on track.


Being new to linux, not that very new as i had been using it(because i liked kde :P) from quite some time. I was new in terms of internals of linux. I was not an expert :-P Same was the case with Qt, though i knew about it, i knew c++, but I had never actually used Qt as the way it is used in Kde, so in short "I was a total newbie" ;-)


/* So the moral of the story is for New Guys who are willing to take part in Google summer of code, dont loose hope just because you are an not an expert. Here we will make you an expert if you are willing to put your efforts in. :) */


Lets get back to track again! :-P
I was new, I was not very experienced, so i was not very confident either. Now that communication had already started between me and my mentor, i got involved in it. When i say i got involved i mean, initially Akonadi, Telepathy were just names for me but now i started to read about them and collect information on them and started taking look at their APi's. I emphasised on the fact  *new* because at the start it is not easy to grasp what exactly things are and how they are actually working.

If somebody else who was a little more experienced then me would have taken a look at it, he might have understood it in a little less time than what i took. I knew this fact so i also knew that, the only thing that can beat my drawback of not being an experienced programmer is that - 'I put in more and more effort!'

So I started to read through documentations, look at the videos of tutorials available, in another words gather as much info as i can before i talk with my mentor on that topic on IRC. This made me tremendously busy and as a result i got completely involved and was not left with any time for other topics i had chosen initially, and so the end result was that I could prepare only one proposal for Google summer of code 2009. I had read at some developer blogs and in some old mail archives that it is always advisable to put in more that one proposal for Gsoc but somehow i was unable to find time for my other ideas and also because This present idea of Akonadi and Telepathy got me interested and everytime i think about it, it produces enegy inside me to work on it.

I am not a kind of guy who will run away from putting an effort into something that i love, and indeed, i am still putting in everything i have! :P


For example when are totally new out from school where you have programmed only simple programs( which max to few 50-100 lines) taking a look at source code of open source applications at one glance will make you nervous. It made me nervous too! First of all there were so many files that I was unable to make out from which file is the execution starting.( i figured that out finally, and so will you! :P)
But my advice is dont quit just by looking at long source code, make and effort and once you get a grasp of it, it will be a piece of cake! Or ask the developers who wrote it, Dont hesitate in asking but at least make sure that you just dont ask anything. We are there to help!

Once the application phase was over, communication had dropped a bit as we were all waiting for the results but as correctly i was advised, "Dont wait for Google summer of code, If you are interested, start working/coding".