A list of things that contributors can do for Tinymail

[Philip Van Hoof <spam pvanhoof be>]

Hi there,

Here's a list of things that would be nice to have and that contributors
can perform:

o. Porting Modest's GtkHTML TnyMimePartView and TnyMsgView to
   libtinymailui-gtk and adapting Modest's to inherit this new class.

 - Coordinate this with Modest's developers
 - Modest's public Subversion is up-to-date enough for this task (all
   its related code is publicised)

o. SMIME support using Seahorse and/or libcst:

 - An implementation of TnyMimePartView
 - Should perhaps go in the platform libraries
 - A static library libtinymail-seahorse?
 - A libcst implementation must be coordinated with Modest's developers

o. Rewriting TnyCamelQueue using GThreadPool

 - Not difficult but affects the inner workings of Tinymail quite a lot

o. Python binding co maintenance (current: Mark Doffman)

o. .NET binding maintenance

o. Vala binding co maintenance (Current: Jürg Billeter)

o. Gtkmm/C++ binding implementation

o. Rewriting all deprecated synchronous APIs to be blocking but using
   the TnyCamelQueue (by wrapping the _async methods and waiting for
   their reply with GCond)

 - tny-camel-send-queue.c has examples of how to do this
 - The GMainLoop can block the callback - issue (perhaps
   don't use GCond but spin a GMainLoop instead)

o. Summary download becomes ENVELOPE + BODYSTRUCTURE

 - There's a bodystructure and envelope parser in 
   libtinymail-camel/camel-lite/bs
 - The summary store rewrite is related to this
 - This is a hard task

o. Summary store rewrite

 - Our current camel-folder-summary.c is one big ugly hack
 - There's experimental code in libtinymail-camel/camel-lite/
   summary/
 - Either wrap that with camel-folder-summary.h's API or
 - Rewrite Camel's usage of CamelFolderSummary (preferred)
 - This is a really hard task


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be