From Fedora Project Wiki
- Email Address: firstname.lastname@example.org
- Telephone: +558387079972
- Blog URL: http://www2.lsd.ufcg.edu.br/~heitor
- Freenode IRC Nick: heitormeira
Why do you want to work with the Fedora Project?
- I like the open source ideology and I admire in a particular way the role that Fedora has in this scenario and I think this a perfect opportunity to give my contribution too.
Do you have any past involvement with the Fedora project or with any another open source project as a contributor (if possible please add some references as well)?
- I did not worked with Fedora before, in my extra class activities I’m extending Dokan (http://dokan-dev.net/en/) functionalities and I pretend to contribute with these extentions to the project.
Did you participate with the past GSoC programs, if so which years, which organizations?
- No, I had not participate of any other editions of GSoC.
Will you continue contributing/ supporting the Fedora project after the GSoC 2012 program, if yes, which team(s)/area(s), you are interested with?
- Yes, I’d love to continue contributing with the project I’m applying to, that is the GlusterFS, since it is an open source project and distribute file system is an area that I’m really interested.
Why should we choose you over the other applicants?
- In my extra class activities we use Dokan with a translator to Java and it gives me the experience necessary in C and binding translators to do it, adding this in my undergraduation we start studying programming languages with python. I love Open Source and distributed file system. I am also particularly excited and interested in work with GlusterFS we always try to have GlusterFS as a guide in the project I participate and I ready to do what will be need to get everything done in time since I will be contributing to an important project.
An overview of your proposal
- I plan to implement a binding translator from python to GlusterFS providing the POSIX file system calls that GlusterFS already offer through a python module, this will create an abstraction layer of the inner workings of the GlusterFS. This translator will connect the api provided by libglusterfs.so with the python world through the Python.h, the header that the language provide to embed python with other programs, the translator must bind all operations (like create, read, setxattr etc) provided by libglusterfs.so without change the actual architeture of GlusterFS and in a way that a python programmer will be able to connect this one, in the simpliest way possible, to his code being possible to manipulate all arguments necessary, without find any limitation.
The need you believe it fulfills
- Programmers would take benefits from the simplicity that is to write python programs (when compared to many other languages including C), that could communicate with GlusterFS structure through this translator. Some applications do not want to use fuse of any other interface like this, so this application could use python to use GlusterFS directly through the translator, instead use fuse interface, as python is a non verbose language and aims the simplicity it would be easier.
Any relevant experience you have
- I have some experience with python, since she is the first contact with programming languages in my course, adding this I'm working with C and a Java translator to connect a C program to a Java program that gives me some experience with binding translators.
How do you intend to implement your proposal
- I'm already starting to study how to embed python with C programs, and I will have some free time that will start next week, so I will be able to completly focus in this project and have something around 20h~30h free per week. I believe that extend GlusterFS will not be easy, but I love file systems and challenges.
Final deliverable of the proposal at the end of the period
- In the end we will have a python module that any program will be able to import and use GlusterFS resources without any limitation compared to others interfaces.
A rough timeline for your progress
- 24/04 - 20/05 - The period that GSoC suggest to know mentors, read documentation etc. We can start modeling the architecture, if this take less time then I can start coding.
- 21/05 - 13/08 - At this time, start to implement the translator. I’m thinking about something around 40 operations with a time to prepare everything. One or two weeks to be comfortable with the code and then four completed operations per week.
- 13/08 ~ Write tests, document everything and write how to’s.
Any other details you feel we should consider
- I think this translator will open doors to people implement applications based on GlusterFS in an easy way.