GSOC 2014/Student Application mohanprakash/Waartaa

From FedoraProject

Jump to: navigation, search
Note.png
please use this template to organize your proposal

Contents

Proposal: WAARTAA

An overview of the proposal

ABSTRACT
This project aims to add more features to Waartaa which is an IRC client as a service. The added features will allow existing IRC users to use their existing IRC clients with Waartaa and will allow multiple clients from different locations to connect to a single Waartaa account at the same time and so they will seem to have the same nickname on IRC.

INTRODUCTION
Waartaa already supports a number of features such as centralized logging, 24x7 idling, notifications and unique identity to a user on IRC. The present status of the IRC client is that is already very attractive and has an easy to use interface. However, the aim of Waartaa is to provide to the user multiple facilities so that both the beginner and the expert can benefit from it. The improvement of the software to this end includes a road map that has been ably highlighted in the project site https://www.waartaa.com/. Out of the objectives highlighted therein, the author aims to implement two additional features in Waartaa. First, Waartaa will be compatible with other IRC clients. Compatibility here signifies the ability of users to use their favorite IRC clients with Waartaa. Second, users will be able to download the logs using the client.

PROBLEM STATEMENT

Many users are already using other IRC clients that support a number of features. Now, these clients may lack some features that are available with Waartaa. So such users may develop a desire to use Waartaa. However since these users are so much familiar with their IRC clients that in spite of the additional features of Waartaa, they might not want to leave their clients and switch over fully to Waartaa. Moreover, their clients may have some special features that are missing in Waartaa. Or it may be simply that the users just do not wish to leave their IRC client as they love it very much. So, to provide them the freedom to use their own favorite client and still avail the additional features of Waartaa, some APIs need to be exposed. This is the first problem that the current project aims to address.
Additionally, in an environment where IP addresses are easily exposed, the users would want their IRC clients to hide their IP address. This beckons the need to be able to set up some sort of concealment, or setting up of some kind of "virtual hosts". We also have a situation for IRC clients in which, when they get disconnected from the IRC server they are in no position to know what state changes take place. It could be nice if Waartaa could remain linked to the IRC server and relay the state changes to the client when it is connected again. Similar is the situation with FTP. Users would like to have the host and servers hidden from each other. This again needs the help of very specialized features.
The present version of the IRC client Waartaa does not allow for users to download chat logs in various formats. It would always be great if the users would have the opportunity to directly download the log files in both text and html format from the IRC client itself. This would save time and add an extra feature that perhaps is not available with many IRC clients being used today. The present project aims to address this problem and work at a solution trying to provide Waartaa with the feature of downloading logs in text and html formats.


The need you believe it fulfills

1. This project will fulfill the need of exposing an API so that users can use their existing IRC clients with Waarta. Moreover, Waartaa will be able to 'conceal' their IP addresses by setting up some kind of "virtual hosts". In the event of the IRC client getting disconnected from the IRC server, Waartaa will remain connected so that when the user connects again through an IRC client, Waartaa will be able to send all the state changes to the client. Then, Waartaa will allow multiple clients from different locations to connect to a single Waartaa account at the same time and so they will seem to have the same nickname on IRC. In this way Waartaa can behave like a bouncer.
2. This project would enable Waartaa to allow users download chat logs in text and html formats.

Any relevant experience you have

1. Study about implementation of IRC clients written in Python and bouncers written in C++.
2. Knowledge about Python programming from a course of EdX/MITX (https://verify.edx.org/cert/207664b4106f42439ff574a2110b6fa9).
3. Thorough concepts of object oriented programming using C++ and Java as I am in my final semester of Masters in Computer Applicatons (http://admission.ignou.ac.in/changeadmdata/AdmissionStatusNew.ASP).
4. Conversant with software engineering methods and feasibility studies.
5. Experience in use of Fedora OS, Git etc.
6. Used SaaP provided by Open Shift in developing an academic project.

How you intend to implement your proposal

Earlier plan
The base class for the external modules may be written in C++ or Python. This base class may have many public functions(modules) to fulfill the following requirements:
1. A module hook which will be called when a module is loaded
2. A module hook which will be called during startup
3. A module which verifies whether a session is active
4. A module which verifies whether the user is an admin
5. A module that checks if the list of registered web pages is correct
6. A module that returns the title on the web interface bar
7. A module to register any subpage
8. A module to remove any registered subpage
9. A module that returns the list of sub-pages
10. A module that can embed things from the web to different places
11. A module that will be called when a user gets disconnected from the IRC server
12. A module that will be called after a successful login to the server
13. A module hook to broadcast message to users
14. Modules to handle situations when a nick is opped or deopped in a channel
15. Modules to handle situations when a nick is voiced or devoiced in a channel
16. Modules to handle situations when command to status or when commands to external modules are sent
17. Modules that handle joining or parting of a nick from a channel
18. A modules that handles change of nickname
19. Modules that return the nickname, etc.
and many other modules

An external module that is written in a language same as the base class can directly inherit from this base class For external modules written in other languages,s there will be other classes that inherit from this base class and then those classes will contain hooks that can be overridden. There will be a necessary documentation so that users can easily write their own modules.
Present plan:
But after advise from Kushal that the work has to be done in NodeJS and not in C++, I had to rethink my strategy. Now I feel the following can be done:
1. NodeJS has a non blocking I/O model combined with JavaScript. This is good for wrapping other data sources. These data sources may be web services or databases.
2. Using a JSON interface, APIs can be exposed. I found that JSON is language-independent and its data structures, arrays and objects, are more or less universally recognized. These structures seem to be supported by many common programming languages, at least those that are commonly used. JSON also seems to be known by many programmers. So data exchange may become very convenient using JSON.

A rough timeline for your progress

Till 20 April

Study open source IRC clients and bouncers

21 April – 30 April

  • linking with the organization
  • discussion with mentors regarding implementation of objective 1
  • Community exchanges for suggestions in objective 1
  • gathering required resources, brushing coding requirements for objective 1

1 May – 10 May

  • discussion with mentors regarding implementation of objective 2
  • community exchanges for suggestions in objective 2
  • gathering required resources, brushing coding requirements for objective 2

11 May – 18 May

  • Software Engineering

19 May – 15 June

  • coding for implementation of objective 1

16 June – 22 June

  • testing and deploying objective 1

23 June :- MID-TERM EVALUATION
24 June – 20 July

  • coding for implementation of objective 2

21 July – 31 July

  • testing and deploying objective 2

1 August – 21 August

  • Documentation

Have you communicated with a potential mentor? If so, who?

Yes, I have communicated with Kushal Das and Ratnadeep Debnath