Complete introspection support for EDS:
This is for evolution-data-server, but only marginally, because the most work might be done in libical, to provide a GObject-based interface for their icalcomponent/icaltimezone/... all structures, basically.
As a starter, the ECalComponent (the wrapper around icalcomponent) can be extended and made introspactable too (it is a GObject descendant already, but some structures are raw structures). The biggest problem is that the ECalComponent can hold only one icalcomponent, not a set of icalcomponents, which is required by ECalClient API, to be able to fetch events with timezones or a recurring event with detached instances. The student may see what is required by the ECalClient API and then propose "the easiest way".
Standalone app for editing server-side Sieve filters:
This doesn't touch evolution's code directly, as it's a prove of concept and a test application to allow editing of Sieve filters directly in evolution. Having it in mind, I'd like to see students with previous Sieve experience and able to discuss the project in #evolution and that end up with a prototype about what will be implemented 'til the end of the applications period.
Notmuch as indexer and search language:
Ideally, a student may create a new CamelIndex descendant, which will talk to Notmuch in the background, and will be usable with CamelFolderSummary (its camel_folder_summary_set_index()). Then the student will touch camel-folder-search.c, because it also uses CamelIndex for body-searches (that's basically the only usage of CamelIndex, for body-searches, but I know the notmuch knows much more).
A similar changes may come into camel-filter-driver.c, together with an addition of "notmuch-code" expression, which will require notmuch for providing output. Then, in evolution, the mail/vfoldertypes.xml,
mail/foltertypes.xml and mail/searchtypes.xml may be extended to also support "notmuch-code" expressions.
As the notmuch project is too much for a SoC period, we would like to have it done only for local Maildir accounts :-)
Implement a simple PKCS#11 module using evolution's addressbook as a backend:
Nowadays we have an address book, and it contains details of X509 certificates for people. But that information is basically in the wrong place. When we come to do S/MIME signing or encryptionm we need the NSS library to be able to find the certificates by the normal lookup process that it uses. In the certificate database(s). So the idea is that the student provides a PKCS#11 module which appears to contain all the keys that are found in the address. When it's asked to search for a certain key, it goes and looks in the addressbook for matching user with an E_CONTACT_X509_CERT field in their addressbook entry and returns that cert, if found.
A nice way to start working on this idea was described on #evolution by David Woodhouse:
<dwmw2> I'd start simple; create a trivial PKCS#11 module with a *hardcoded* cert in it. Just one
<dwmw2> so you can send email to that user and it can find that cert in your module
<dwmw2> that'll get you putting together the basic guts of the PKCS#11 module with its search and get certs functions.
<dwmw2> and wiring it into the right place in Evolution to *use* it
<dwmw2> then after that, we make it a proper addressbook client and make it do the right search in the addressbook for *real* data.
If something is not clear and/or you want to discuss the ideas, please visit the #evolution channel or send us an email through evolution-hackers mailing list (https://mail.gnome.org/mailman/listinfo/evolution-hackers) and we will be glad to help with anything that is necessary.