GSOC 2013/Student Application tiagolam

Contact Information

• Your name: Tiago Lam
• FAS Account: tiagolam
• Fedora userpage: https://fedoraproject.org/wiki/tiagolam
• Email Address: tiagolam [AT] gmail [DOT] com
• Blog URL: http://tiagolam.blogs.ua.sapo.pt
• Freenode IRC Nick: tiagolam

NOTE: We require all students to blog about the progress of their project. You are strongly encouraged to register on the Freenode network and participate in our IRC channels. For more information and other instructions contact Org Admins.

please answer following questions

Why do you want to work with the Fedora Project?

• Starting with a little bit of background, Fedora has always been my main reference when it comes to Open Source. I started using it back in July/August of 2008 when I installed Fedora 9. My main reason for switching from Windows to Linux was my curiosity/fascination for the Open Source world in general - and also, at the time, I just got tired of all of that Vista slowness. The other reason was that I was going to University (to take a Computer Science course), and I just felt it was a good opportunity to become friends with the penguin.
• In Fedora, I've seen how much computer people can give to the community without wanting anything back. A simple 'thank you' or 'kudo' suffice, and honestly, I can identify with that. Doing a project that you like, seeing it flourish is by itself a great reward. I know that the same morals exist in pretty much all of the other Open Source Projects, but the reason I want to work with Fedora in particular, it's because of the efforts that the community makes to always try to include the most recent and up to date tools/programs (which sometimes breaks things, but I guess that's a consequence of being at the edge).

Do you have any past involvement with the Fedora project or any other open source project as a contributor?

• No, I haven't had any opportunity to work on any open source project yet.

Did you participate with the past GSoC programs, if so which years, which organizations?

• No, unfortunately I haven't participated in any of the previous GSoC.

Will you continue contributing/ supporting the Fedora project after the GSoC 2013 program, if yes, which team(s), you are interested with?

• Definitely. That's one of the reasons why I'm participating in GSoC. Not only to contribute to an Open Source Project, but also to introduce my way into Fedora, so I can continue later, not only as a package maintainer, but also help with new ideas for the Fedora Project and developing those ideas - hence my purpose of participating in the Infrastructure team in the future.

• I may add that I've been reading the main mailing lists (Devel, Announce and Test) for almost 6 months. Although I haven't participated or introduced myself (which I will, in a near near future), my main reason to subscribe was to gain some internal knowledge about how Fedora works - some things could be read of the wiki (which I read), but in my opinion, some other things can only be understood with real problem/solution scenarios. The other reason was that I also want to become a package maintainer, as I said in the previous paragraph. I have started - and finished - the packaging of a program called mitmproxy, which is a SSL man in the middle HTTP proxy. I am in the process of making my final self-review of the package (to see if I missed something), and then also package a dependency, netlib, which is not in Fedora repositories either. Then I can submit my first two packages for review, and finally introduce myself.

Why should we choose you over other applicants?

• I have the necessary knowledge prerequisites:
  • I've done projects in C and Python, and although I am familiar with Python extension (let Python call C), I've not yet worked with embedded Python (letting C call Python), but to fill that gap I've already started looking into Python ctypes.
  • In those projects I used SVN and Git as a SCM and so, setting up a distributed environment for developing/contributing isn't going to be a problem (In my University we use an internal storage server for hosting all our Git/SVN projects, but I have already a GitHub account).

• As a final point, although I've never participated in a real Open Source Project I believe we have to start somewhere, and I have the necessary knowledge and character to easily adapt myself.

Proposal Description

An overview of your proposal

• With this proposal I plan to implement a Python translator module that uses the GlusterFS translators APIs. Since the APIs are provided in C (libglusterfs), Python ctypes will be used to enable calling C code from Python code and vice-versa, which means calling Python code from C code, thus binding Python with the C APIs. By the end of the implementation it is expected that the final Python translator module provides, *at least*, the most important operations of the translators APIs - to see the operations that are considered to be the most important please refer to the below 'Final deliverable' point - that will ease the development of some GlusterFS related tasks in Python scripts.

The need you believe it fulfills

• The main objective of this proposal is to develop a more high-level API (in this case provided by a Python module) that programmers can use in the development of their programs/scripts. With that abstraction, programmers don't have to deal directly with the GlusterFS API, having a more friendly way to use GlusterFS in their programs, which ultimately will increase the number of developers that willing to contribute/use GlusterFS.

Any relevant experience you have

• As stated before, I've done projects in both C and Python, and I'm also familiar with Python extension.

• In 2010, as a project for a discipline in my course, me and more 4 colleagues of mine implemented, tested and debugged part of a file system using FUSE (The file system was incomplete, deliberately, for the purpose of the discipline).

How you intend to implement your proposal

• Dividing the proposal in it's main keywords, we have two words that stand out, *binding* and *translator*:
  • The former is a terminology of GlusterFS to designate a module that has a very specific functionality. Basically, it reads the received data, processes that data (to achieve the desired functionality), and passes it again, which can be received by another translator (and is processed again), or arrive to it's destiny.
  • The later is simply the definition of a bind, which means that the final desired functionality will be provided by a Python module, binded to the translator.

• Regarding the implementation of this proposal, the translator will be the first part being implemented. This translator will be implemented in C, and will deal directly with the libglusterfs translator APIs. We can see this translator as an intermediate piece of code that will be responsible of complying with the internal structure that translators need to have in order to be loaded correctly, like the init function and fops dispatching table.
• In the second part of the implementation, the binding part, the developed Python module will bind to the translator developed in the first part and take advantage of the abstraction created, to provide to future Python scripts a more clean way to interact with GlusterFS.

• An image that reflects the explanation above follows:

• An advantage of this proposal is that one can after do a bind with any other language, given that the language supports binding with C, and the translator part, implemented in C, doesn't need to be modified.

A rough timeline for your progress

• 1. ~May 27. Preparation - Learn how translator works (init, finit, fops, and other internal structures).

• 2. ~May 31. Preparation - Set up Glusterfs environment to be able to use it.

• 3. ~June 4. Preparation - Continue to learn more about GlusterFS translators (this phase is more oriented to it's APIs).

• 4. ~June 17. Coding - Start writting a simple translator (to have a more concrete notion of how it works - and to apply knowledge gained from the preparation fase). Possibly start with open, lookup and stat/fstat operations.

• 5. ~June 24. Coding - Start writing a simple python module to bind to the first (and yet very simple) version of the translator. Test and debug that python module.

• 6. ~July 1. Coding - Extend translator operations - creates, reads, removes and setattr.

• 7. ~July 15. Coding - Write a simple Python script that uses the python module to perform some simple tasks.

• 8. ~July 25. Coding - Write tests and documentation of code. Keep extending the translator operations.

• 9. ~August 1 to August 15. Coding - Finalize the implementation of the most important operations (according to the proposal).

• 10. ~September 1. Room for improvisation - Highly possible that in this time will be implemented extra operations - operation that were not considered in the proposal.

• 11. ~September 20. Start finalizing code, tests and documentation for deliver.

Any other details you feel we should consider

• As a final point in my proposal, I have to add that I'm in the final year of my MsC and so, I will also be doing my dissertation during this period. This is the last year that I will be able to apply to GSoC, but I've planned all this throw so that I don't have to sacrifice either parts.

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

• I tried, but since they were not responding, and given the short time, I thought it would be better to make my application first, and then get in contact with them.