SoC/Ideas
From OpenChange wiki
This page contains ideas for the Google Summer of Code. OpenChange was involved for the first time in 2008, and is involved again for GSoC_2009.
If one of these projects interest you, or you have an idea you'd like to try, please send an email to summercode@openchange.org or contact us on IRC #openchange on irc.freenode.net.
For more guidance, also check out GSoC_Guidance.
For all projects, it is useful if you are somewhat familiar with the Messaging API (MAPI) that exists on Windows. Basic knowledge of C is also recommended for all projects (and required for some), as it will help you read the OpenChange source code if the API documentation is incomplete.
Contents |
OpenChange tools graphical front-end
OpenChange provides some command-line tools which have numerous features but can sometimes confuse users. An interesting project for the Google Summer of Code would be to create graphical front-ends (Gtk and/or Qt) for openchange tools, and also to work on integrating administrative tools for Gnome/KDE. This will help make OpenChange more accessible to users, who currently need to use command-line tools in a lot of situations.
Useful skills for this type of project would be toolkit experience (e.g. experience with Gtk or Qt) and some programming experience with C libraries. You would probably need access to a Microsoft Exchange server for this project.
- Possible mentors: Julien, Jelmer
- Language(s): Python or C depending on your preference.
- Difficulty: Easy
- Skills: GUI toolkit (e.g. GTK or Qt), C programming experience, some UI design experience
Thunderbird Integration
Mozilla Thunderbird is an email client that currently supports the POP and IMAP protocols to retrieve data. An interesting project for the Summer of Code would be to create a proof of concept patch for Thunderbird that allowed it to fetch email over MAPI within Linux. The patch can not land as-is inside of Thunderbird itself since it is MPL/GPLv2+ dual-licensed (and not intending to relicense to GPLv3+), and OpenChange is licensed under GPLv3 or later.
However, once such a patch exists, it would allow us to tell the Thunderbird developers what required features are missing from the Thunderbird extension API. After Thunderbird's extension API is fixed, the proof of concept patch could be used as a basis for an OpenChange extension for Thunderbird (these last two steps would be beyond the scope of the SoC project).
An OpenChange extension for Thunderbird would of course make a lot of Linux users that are still tied to a corporate Exchange server very happy. It would help get OpenChange installed on a large number of systems, and thus help improve the quality of the OpenChange client libraries and protocol implementation.
- Possible mentors: Julien, Jelmer
- Language(s): C++, C, JavaScript
- Difficulty: Hard
- Skills: Familiarity with XUL, XPCOM
Additional Akonadi (KDE) work
The KDE Personal Information Management storage / access backend is called Akonadi. Some work has already been done on this as part of GSoC 2008, but there is plenty still to do.
Useful skills for this type of project would be familiarity with Qt and KDE and some C programming experience. C++ experience with Boost might also be useful. You would probably need access to a Microsoft Exchange server for this project.
This project would be useful for similar reasons as the Thunderbird integration; it would make a lot of users very happy.
- Possible mentors: Julien, Brad
- Language(s): C++, C
- Difficulty: Medium
- Skills: Qt, Boost experience
Exchange / ICal tool
There is a specification for converting between the Microsoft Exchange representation and standard ICalendar representation. OpenChange has a partial implementation (called exchange2ical) that downloads the user's calendar, but more work is required to make it complete, robust and compliant with the spec. In addition, it would be useful to also be able to upload a calendar. This should allow users to work with an Open Standard (iCal) and the applications that support it on Linux, while still being able to share their calendar with their co-workers who are using Exchange or Outlook.
Useful skills for this type of project would be familiarity with C programming (especially using external libraries). You would probably need access to a Microsoft Exchange server for this project.
- Possible mentors: Brad, Julien
- Languages: C
- Difficulty: Easy
- Skills: Experience with libical would be useful, otherwise C programming
Perl bindings
Scripting languages like Perl are more accessible than plain C. System administrators often use perl to customize and automate their systems. With Perl bindings for OpenChange, they would be able to do this for their Exchange servers as well.
OpenChange has some very simple Perl bindings created with the SWIG framework at the moment. Your job would be to build new Perl bindings that can be used for most common MAPI operations. You can create the bindings either using SWIG or C, but one of the conditions is that they will feel "Perlish" to a Perl developer, they should not simply imitate the C API.
- Possible mentors: Julien, Jelmer
- Language(s): C, Perl, (SWIG?)
- Difficulty: Medium
- Skills: you'd need solid experience with Perl to design the bindings / API.
Test Servers
It would be very useful to be able to run automated tests after each checkin that make sure everything is working the way it should. We have a Buildbot set up at [1] but it doesn't do much on the server side. If we had a server that produced known responses (e.g. a certain number of messages, known contents, and so on) we could add specific tests that verify the client libraries read the correct response. This would help sustain the quality of the code in the OpenChange project, as it would make it a lot easier to detect when regressions are introduced.
We could also create servers that produce nasty responses (broken operations, incorrect lengths or bad encoding) and check that the client libraries can survive that.
This type of project would require strong C programming ability, and some previous network programming experience would be useful. Access to a Microsoft exchange server might be an advantage, but probably wouldn't be important.
- Possible mentors: Julien, Brad, Jelmer
- Difficulty: Hard
- Language(s): C, Python, Shell
- Skills: Broad programming experience, understanding of LDIF
