|
|
Nybyggerne.dk WebUglen BirthdayReminder MasterMind SudokuSolver OpenPop |
OpenPop.NET is a C# library that enables users to download and parse email messages from a POP3 server in a simple way. OpenPop.NET was created in 2004 by hamidsforge and unruledboy. The project slowly grew and in 2009 I found it myself. I was using OpenPop.NET on Linux under MONO, and found that it had never been tested on this platform. I found some bugs which made the project unusable under Linux. As it was opensource, I thought I might as well contribute by telling about the bugs and how to fix them to the authors. The authors told me that the project had been dead since 2006, and they therefore did not want to fix the bugs I had found themselves. So instead they offered me the project, and I accepted. The code was being revisioned under CVS - which at that time had been outdated by standard. Since I did not have a CVS client, and I thought most other people did not as well, I wanted to change from CVS to SVN. When SVN was in place and running, I began converting the project files from older Visual Studio formats into newer ones. When I at last had everything compiling, I could change two lines in the code to fix the bugs I found - Success! I then began exploring the code. What I found was a mess: it was not intuitive, lots of code did nothing and there was dependencies in all directions. As I got deeper and deeper into the code and my understanding of POP3 and MIME grew, I found that the code had bugs everywhere. Also, even the simplest of tasks had been written in complex ways. It was really hard to see what the code did and why. The next natural step was to bring order into the chaotic code - something had to be done. I began refactoring, slowly bringing the code into a more maintainable form. I read the POP3 and MIME RFCs to gain knowledge of the problem domain. A half year had now passed since I first took over the project. At this point I received company - John McDaniel joined because he wanted to make some changes to the project. We began sparring about what to do with the bugs - he helped make the interface cleaner and better. He also fixed some bugs which I had not found myself. We discussed if we needed test cases, and we ended up bringing in a lot of them. We also had a lot of test cases that failed, test cases that showed there was still bugs to be found. These test cases had to be fixed - and that was when I started on a very large refactoring. The project had one big bug, which was when the project (not) tried to handle international characters. In essence, the project worked with Strings, even though it was not possible to convert the bytes received from a POP3 server into Strings. The project had to be changed to work with bytes instead, and then convert the bytes into Strings when enough knowledge was gained about the content. When this refactoring was completed - the project had a much cleaner interface. Many of the bugs were fixed, and soon no known bugs was around. At this point today, when I write this text, there is no known bugs. It is now believed that the project can handle all emails that comply to the standard defined in the relevant RFCs. Now and then an email is received at the project mailing list when a user found an email the project could not parse. Mostly this is because of the email not complying to the standard, but some times it is a full blown bug in the project. Each time, a test case is implemented and then the parser is changed the handle the non-conforming email, or the bug is fixed. Now - there is not much work left in the project. What is needed is a coordinator that simply fixes the bugs reported by users. I feel the project is very strong now, it has a community on the mailing lists and it is getting better for each change that is made to it. It is surely something that I am proud of! |
| Last modified 10. October 2016 | foens@cs.au.dk |
|