This page lists some potential ideas that could be offered to students if gPodder participates in GSoC 2013.
If you are interested in implementing one of these project, please write to the gPodder Mailing List.
If you would like to contribute a new idea, just add it to the list. If you can also mentor it, even better!
gPodder 3.0.0 removed support for the old method of syncing podcasts to portable audio players. Some people have expressed their sadness about seeing that feature go. The feature as it was implemented in 2.x was not well maintained, and while it worked, it didn't provide the necessary flexibility that users demanded, so we decided to remove it in 3.x (which also made it possible to clean up some other spots). Of course, there's no problem with re-implementing an even better device sync module for 3.x.  
Right now, gPodder 3 only has support for filesystem-based MP3 players. The goal of this project is to implement iPod and MTP device sync, as well as update and clean up the MP3 player sync code.
Currently there is only an experimental Web UI (HTML-based) on top of the Python codebase, running inside SL4A. The Android lifecycle is not really followed, and it's not too well integrated into the Android system.
Provide a native podcast client for Android, similar to the mobile versions of gPodder for Maemo. The backend should have the same package/class structure as the Python backend, but utilizing Java technologies and libraries. Students are expected to exchange ideas on architecture/structure improvements, and those can be merged into the Python backend as well (so that at the end of the project, the Python backend and Java backend are feature-wise and structurally "in sync").
However, playing podcasts via gpodder.net could be handy when you are using a friend's/work computer or if your plattform isn't supported by the gPodder client.
The goal of this project is to extend the gpodder.net webservice so that podcasts (ideally both audio and video) can be played via the web. As with the gPodder client, feedback such as play-events should be fed back to the webservice.
The web-based client should be able to act as a virtual device (in the gpodder.net terminology) which would enable it to manage its own subscription list, sync with other real devices, have its own history, etc.
Probably this would involve combining multiple solutions such as
Currently gpodder.net offers a simple podcast directory which lists the most-used categories and their most-subscribed podcasts. However, this directory can only be accessed via the webservice but not from within gPodder.
The goal of this project is to integrate the gpodder.net podcast directory into gPodder so that categories can be listed, browsed and podcasts from these categories can be subscribed from within gPodder.
Currently users can synchronize podcast subscriptions and episode states between a number of clients. However, there are many more podcast clients that still lack the ability to synchronize with gpodder.net.
The goal of this project is to integrate you favourite podcast client (Banshee, Rhythmbox, iTunes, WinAmp ...) with gpodder.net so that users of the client can make use of
gPodder supports a D-Bus API for receiving playback events (started, stopped - both with position information) that can be used to synchronize the playback progress to gpodder.net and with other devices. Support for this API has been implemented in gPodder for Maemo 5 through the MAFW plug-in, and preliminary support also exists in [Panucci].
The goal of this project is to write plug-ins for the following Desktop media players. The list of media players is negotiable, if you want to add your favourite media player, but want to skip one of the players in this list, that's okay, but please specify the list of media players in your application.
RSS and Atom feeds are commonly used to distribute and describe podcasts. Due to their generic definition, they can be ambigously interpreted for the use case of podcasts. This often resulted in incompatible uses of these standards which then caused problems when processing some podcast feeds.
The gPodder project is currently creating a best practice guide for publishing and interpreting podcast feeds.
The goals of this project are to automate the evaluation of a podcast feed against the guidelines, and to collect statistics based on such an evaluation. An extensive list of podcast feeds would be provided for the execution of the evaluation.
The student would learn how to read and interpret best-practices guide and related standards. She would further learn how to transfer such texts into an implementation, and would be able to test the resulting work on a large number of real podcast feeds.
The project would benefit from this project in several ways. It could provide podcast publishers feedback about the quality of their podcast feeds. The work would yield results that could help to further improve the podcast parser. Additionally the real-world applicability of the best-practices guide would be evaluated.
gpodder.net uses CouchDB as its main data store. Currently the data of all users (and pocasts) is contained in one database, which makes queries easy (because data of all document types can be combined in views), but makes the handling of data inflexible.
Some work has already be done to split the main database into several smaller ones that can hold the data of one user or a group of users. This would requires directing queries to the correct databases, and producing aggregated data from a set of databases instead of a single one.
In this project the student could learn to design and implement a distributed application backend. The project involves issues like scaling, failure scenarios and query distribution, for which guidance would be provided. The student could learn the trade-offs of different application architectures in real-life situations.
With this idea implemented, the project could make better use of small, low-powered servers for running gpodder.net (especially as the webservice is funded by donations). It would also allow more flexible data migration between servers for scaling and maintenance.
Podcatcher is one of the major (open source) podcast client available for Windows Phone. It currently offers podcast search and user's subscription import through the gpodder.net service. But gpodder.net provides a lot more potential that Podcatcher could leverage which would also benefit the users of gpodder.net.
The goal of the project is to expand the support of gpodder.net in Podcatcher. With this project, gpodder.net users' podcast information would be synced two ways; from gpodder.net to the Podcatcher client as well as from the client to gpodder.net. The information that would be synced is users' podcast subscriptions and episode listening states within those subscriptions. This way users would have all their podcast information synced throughout all his/her devices.
The student would be able to learn Windows Phone development, database design and programming on the Windows Phone platform with LINQ as well as client-server programming with REST APIs and data processing.
With this idea implemented, gpodder.net would have a major Windows Phone podcast client support the majority of its main features. This would benefit both the users of gpodder.net as well as the users of Podcatcher.
Volksempfänger is an open source podcast client available for Android. It currently offers podcast search through the gpodder.net service. But gpodder.net provides a lot more potential that Volksempfänger could leverage which would also benefit the users of gpodder.net. To prevent confusion it should be mentioned that the app probably will be renamed to "HoloPod" on the next release.
The goal of the project is to expand the support of gpodder.net in Volksempfänger. With this project, gpodder.net users' podcast information would be synced two ways; from gpodder.net to the Volksempfänger client as well as from the client to gpodder.net. The information that would be synced is users' podcast subscriptions and episode listening states within those subscriptions. This way users would have all their podcast information synced throughout all her devices.
The student would be able to learn developing for the Android platform. She especially would learn how to integrate an App with an webservice but also get to know many other parts of the platform, for example how to integrate accounts into the Android system.
With this idea implemented, gpodder.net would have an Android podcast client support the majority of its main features. This would benefit both the users of gpodder.net as well as the users of Volksempfänger.