User:Diadara/GSoC2014
Personal information
- Name: Nithin Saji
- Email Address: nithin111@gmail.com
- Blog URL: diadara.github.io
- Freenode IRC Nick: diadara
Your university and current education
I am currently enrolled in fourth year of a dual degree program in physics and computer science form Birla Institute of Technology and Science, Pilani.
Why do you want to work with the Swathanthra Malayalam Computing ?
I have participated in last years GSoC with SMC. Last year I applied because of the novelty of working for an organization that wants to bring computing to people in the language they want. This year I feel very much a part of the community and want to participate just to get involved.
Do you have any past involvement with the Swathanthra Malayalam Computing or another open source project as a contributor ? Did you participate with the past GSoC programs, if so which years, which organizations ?
I participated in GSoC 2013 with the SMC with the silpa project. I am an avid open-source enthusiast and try to get involved with projects that I use. I have made small contributions to some projects. I also put all the trivial scripts and configs that I write on Github title.
Do you have other obligations between May and August ?
Last year I had grossly under estimated the workload, I had classes during the last one and a half month of the program and couldn't work as much as I would have liked.This years time is more favorable to me as I will be available full time, apart from a week during the community bonding period I won't available due to exams.
Will you continue contributing/ supporting the Swathanthra Malayalam Computing after the GSoC 2014 program, if yes, which area(s), you are interested in ?
SMC is the first open-source organization, I have gotten involved with. I have learned a lot from last years GSoC working with SMC and project-silpa is very dear to me now. I would certainly get involved more.
Why should we choose you over other applicants ?
I passed the evaluation successfully even though I could not complete all the tasks from my timeline as the project evolved during the coding period and I grossly under estimated the time requirements needed for planning and testing. This year I am a lot more experienced and I have gone through almost every line of code in the project-silpa repos. I believe my past experience will help me during the course of the project. Also I believe I have the required command over the programming languages used in project to complete them successfully.
Proposal Description
I would like to combine two, ideas from the ideas list that struck me. I believe both of these can be completed successfully in the given timeline
1. Porting varnam to SILPA
Silpa modules are written in python and have a uniform interface across the modules. In order to integrate varnam with silpa, we will have to port libvarnam to python. I have gone through api.h and the implementation of ruby and nodejs bindings for libvarnam.
There are several approaches available for calling c code from python,
- use the python c api to build a module
This how python standard libraries are build.However this method can be error prone as we will have to do memory manaagement ourself.
- wrapper library generators such as swig,
This is a viable option however it could be overkill as our api is not too big.
- ctypes module in python which can be used to call functions from shared object files.This is similar to the FFI ruby gem used in the ruby wrapper for libvarnam.
I feel ctypes based port will be a better choice for porting as we wouldn't have to deal with low level python c api and also since the library is small enough to be ported using ctypes.wo
Once the library is ported to python I could make a template file and add a varnam module to project-silpa. I have been using python and c for a variety of projects.(academic and personal) and I am confident that this can be done within 2-3 weeks.
2. Varnam Daemon
If the above project goes successfull, then we will have bindings for ruby,python and nodejs for libvarnam.However, if we want to port it into something else, we would have tp go through the same dance again. The solution to this can be a varnam server that can communicate to multiple processes through the socket API.
I would like to implement varnam daemon as json-rpc2.0 compliant API over raw TCP sockets I have some experience with sockets from my computer networks course work and can learn more during the course of the project.Here are some reference implementations for JSON-RPC over TCP JSON-RPC.This would enable varnam to be used in any platform that supports sockets and most languages have json rpc client libraries that work over tcp and it will be straight forward to use libvarnam without a a dedicated client library.
JSON-RPC2.0 is a stateless protocol and varnam api passes around a handle to maintain state. This would have to be taken care with a wrapper to the api calls.
Once the protocol is finalized and the daemon is made. I would also make a couple of reference implementations for the library in python and php.
Time line
community bonding period
I have played around with varnam api and familiar with all the functions that needs to be ported.The python port won't be a direct one to one translation of the function calls due to the difference in features of the programming style.However the python port should be very similar to the ruby port and we would be using a similar api.I would use the community bonding period to get familiar with ctypes and documenting the api.
Also during this period I would be reading source code from some of the referece JSON-RPC implimentation I have linked above apart from studying various methods to achieve concurrent connection handling by the varnam daemon. As the daemon is expected to be run on localhost and is not supposed to handle large number of connections a multiprocess model using fork() 1 will be used. I would spend some time to get familiar with the preforking architecture and design a suitable architecture for the libvarnam daemon.
Week 1:
I would start by writing tests for the varnam-silpa and follow TDD for this project.I would work on a varnam-python.py version similar to the varnamruby.rb using ctypes module. This would require ctypes datastructures for handling the custom datatypes used by libvarnam, Once this is complete I can write a silpa style python class based module for it.
week 2
Complete python-varnam. Create a silpa-flask template for it and integrate to silpa. I am very familiar with this part.
week 3
Build a simple socket server application that can accept JSON-RPC requests. jsonrpc-c contains an implementation for a JSON-RPC request validator that is independent of transport layer. [1] is a simple socket server that can handle JSON-RPC requests. I would be building something similar to the later project.
week 4
As I mentioned earlier, varnam needs to be initialized before use and JSON-RPC is stateless. I would be designing a config file based init system for varnam daemon. The user will be able to specify suggestions directory, symbol directory, ports etc using this config system.Main goals for this week would be the config parser.
week 5
Integrate the config parser, the socket server with JSON-RPC and libvarnam.I would be writing wrapper functions around libvarnam functions to integrate with RPC interface.
week 6
A basic version of the daemon should be ready by now. This week will be spend on perfomance optimization of the server to make it handle more connections. Also the architecture of the server will also be changed for this pupose from a single process, single threaded application to a more advanced model.
Mid Term Evaluations
week 7
Further improvements on the server, check for memory leaks or other issues.
week 8
Refinement of the commandline interface of the daemon
week 9
Make sure the system works in windows as well, modify the system to work with winsock and systemcalls available in windows.
week 10
write example clients for python and php
week 11
Support the daemon to be run with init systems like systemd. Package the system for various popular operating systems.
week 12
Buffer week for unforeseen problems that I may encounter during the process.
POST GSOC
I would also like to port libvarnam to Android using Android NDK. There is libvarnam-java already but, an android sdk has it's use cases.I was not sure I could complete this during GSoC coding period.
