Implementation of chat log browser – GSoC Week 2

Last week’s task was to implement chat log browser. It basically required working on three things, namely search API, UI and their integration.

Search API

The first thing I had to do was discuss with mentor and finalize API endpoints. We ended up with only one endpoint.


  • {server-name} is eg. Freenode and it is case-sensitive in search query.
  • {channel-name-without-#} is eg. fedora-admin and it is case-sensitive too in search query.
  • {get-params} All of the below get parameters are optional.
    • message: search term eg. ‘trouble installing Fedora’
    • from: message sent by eg. dne0
    • to: message sent from: rtnpro
    • dateFrom: message was sent after date eg. 1 May 2014
    • dateTo: message was sent before date eg. 10  May 2014
    • page: for pagination

Obviously, all these parameters are first validated before querying from elasticsearch. And then results are returned in JSON format as shown below:

  status: <bool>,
  errors: <array>,
  results: {
    totalCount: <int>,
    perPage: <int>,
    took: <int>, // time taken in milliseconds
    data: <array of objects>

For routing we are using Iron Router, but there are some issues with its server side router. I hope they get resolved quickly so that I can refactor API code and make it look more cleaner 🙂

Search UI

Being a novice in designing and HTML/CSS, I tried not to waste much time on fonts/color scheme and instead focused more on adding possible search fields which user might want to use to narrow down search results. Currently, UI contains option to select channel, search by message and some advance search options like date, from, to etc.

UI & API Integration

Meteor provides a http package for sending asynchronous requests. I have used this package in my code to call API. As written earlier, the results we get are in JSON format, this JSON is rendered on client side using UI.toHTML api of meteor.

callAPI: function (serverName, channelName, getParams) {
  var API_URL = this.getAPIEnpoint(serverName, channelName, getParams);
  Meteor.http.get(API_URL, function (err, body) {
    if (!err) {;
    } else {
      alert('OOPS! An error occured while fetching data.');


With this, the first version of chat log browser is ready. Here is the PR:

Screenshot from 2014-06-04 15:09:15

Screenshot from 2014-06-04 12:45:09

Please note search terms are highlighted. Thanks to elasticsearch’s highlight search terms feature which made it easy to implement.

PS: Any suggestions for improving the search interface or anything else are welcome 🙂

What’s left?

  • Refactoring API code.
  • Authentication mechanism in API.
  • Improving UI.
  • Implementing chat log permalink and bookmarking feature.

<script>JS I love you</script>

Hacking on Waartaa – GSoC Community Bonding Period

Bit of a late, but yes, I have been selected in Google Summer of Code(GSoC) with The Fedora Project to hack on Waartaa. Ratnadeep Debnath(rtnpro) and Sayan Chowdhury are my mentors.

Waartaa is an open source, modern IRC client for the web. It supports centralized logging, 24×7 idling, notifications and unique identity to a user on IRC across multiple clients/devices, and also a rich UI for awesome user experience. During GSoC tenure, I plan to implement:

  • A central hub for searching/reading channel logs.
  • Bookmarking channel logs.
  • Video/audio conferencing facility.
  • Admin console panel in Waartaa.

Check out my detailed GSoC proposal for more info.

It has been a pretty exciting last three weeks. I simply love Javascript and the thought that Waartaa is a Meteor based project excites me to spend even more time on this project. Below are the things I have done/coded so far.

Setting up Waartaa

Before I was selected for GSoC, I had installed Waartaa on Ubuntu. But later I was told to set up Waartaa on Fedora for future development work. And so I did. Unfortunately, it took more time than I anticipated because of some partition issues in my laptop. I am glad that it has been set up properly now.

Indexing Channel Logs in Elastic Search

To implement a central hub for searching/reading channel logs, it is obviously necessary to store logs somewhere first. Waartaa’s current implementation saves channel logs in MongoDB but it is highly unoptimized for full text search. My mentors decided to use Elastic Search considering its full text search capability. Here is the basic code I have written to save channel logs in elastic search:

Fixing few minor issues

I fixed few minor issues as well. Both of them were client side related issues. Below are the PRs I sent:

Unit testing

I was told to get familiar with the code base by unit testing it. There were no previous unit tests in Waartaa’s code base so I had to start everything from scratch. There aren’t many unit testing frameworks available for Meteor. RTD test runner was our best option. RTD uses Jasmine as it’s default unit testing framework and it has a good documentation available. So writing unit tests was not as hard as I thought it would be. Till now I have written tests for client side template methods and events only. Here is the PR which I sent recently:

Please subscribe to get notifications of future posts on my GSoC work. Till then happy summer and happy hacking! 🙂

<script>JS I love you</script>