Re: Future items for tinymail

[Philip Van Hoof <spam pvanhoof be>]

ps. Companies who would like to fund any of these, please contact me so
that I can get the right professionals on it.

Or .. if you would like another feature, same :-)


On Thu, 2007-02-22 at 13:01 +0100, Philip Van Hoof wrote:
> Future:
> 
> On-demand MIME parts. The default download mode will be like partial
> message retrieval. At the time that the user needs a mime-part, it will
> be downloaded. Entire messages are never downloaded (only mime parts are
> downloaded, the HEADER and the 1 being just two of them).
> 
> Summary in multiple mmap()-ed files. Holes and letting it grow is the
> current biggest problem with the summary storage of tinymail. In stead
> of using one big mmap()ed file, I want to use multiple files.
> 
> The changeable data of the summary in a different file. The flags are
> the only data that change. Yet changes to these flags cause full
> rewrites of the summary mmap()ed files. I want to store the flags in a
> different file on the filesystem.
> 
> Forward-without-download: Lemonade specifies the possibility to make a
> message out of mime parts without having to get the mime parts locally.
> For example forwarding a message without having to store the to-forward
> message locally. This is done using some cooperation between the ESMTP
> and the IMAP4 server. I want tinymail to support this.
> 
> Better synchronization: Right now if the first (oldest) message got
> removed by another E-mail client, tinymail must fully remove the entire
> local summary for it doesn't know the correct sequence numbers anymore.
> I want tinymail to better cope with this, predict it and don't just
> assume that everything has become incorrect. Usually most is still
> correct and some extra code can figure out a lot things about this,
> rather than just removing everything.
> 
> Incremental filling up the view (and the things that get caused by that,
> which I will write about below this dialog of text): issuing the folder-
> changed signal faster (for example each 1000th header) and passing it to
> the folder-observers more early. Making demos for this and preparing the
> tinymail API for it.
> 
> Incrementally filling up the view means that the user can start doing
> things like downloading messages WHILE this is happening. I want
> tinymail to open ONE second connection for this and ONLY if in the
> background the main IMAP connection is in used CAUSED by a background
> incremental download of summary information.
> 
> 
> 
> _______________________________________________
> tinymail-devel-list mailing list
> tinymail-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/tinymail-devel-list