Roadmap to a Tinymail 2.0 API and implementation

Summary code

The idea is to basically rewrite camel-folder-summary.c from scratch:

  • Writing the summary in multiple files of 4kb
  • Only the last file is writable
  • The others are read-only mmaped and sealed
  • Having the flags in a separate writable file

Lists

libgee's list API

  • One person has started working on a high level API with some types like lists. These might be usuable to replace TnyList, for example

Streams

GVFS's stream API

  • The GVFS team are building an API for streaming GInputStream, GOutputStream and GSeekable. These are excellent for replacing TnyStream with.

Queues

Abstract queue interface

Right now libtinymail-queues simply depends on AsyncWorker. The idea is to make the queue itself abstract in Tinymail, so that the developer can choose to implement it himselve. Of course provide a default implementation on top of AsyncWorker, for example.

One example would be to have a an interface TnyQueue that all types described below implement. One core implementation would be called TnyAsyncWorkerQueue. All of the types below would always decorate a TnyQueue, and pass the task itself to the instane that they are decorating. This way it would be possible to nest types in each other. Very much like the Stream APIs of Java and .NET.

For sending messages

In libtinymail-queues a TnyGenericSendQueue has been implemented. The idea is to futher test and extend that type.

For getting messages

In libtinymail-queues a TnyGetMsgQueue has been implemented. The idea is to make it possible to pass the queue implementation (so that this queue can be shared with other to-queue operations).

For getting full messages

In libtinymail-queues in TnyGetMsgQueue functionality for this been implemented. The idea is wrap this functionality into a new type, for example called TnyFullMsgRetrieveQueue, that would decorate an existing TnyGetMsgQueue.

A TnySearchFolder

The idea is to have a TnyHeader and a TnyFolder implementation that implements tny_folder_get_headers by calling that method on n folders, and storing each result to a temporary file (sequentially or sorted or something). Unreferencing the header instances and the nth folder and then creating a new temporary (or virtual) folder based on that just created file (mmap).

The TnyHeader implementation would in stead of using camel-folder-summary.c for this, immediately use the pointers in that mmap-ed file.

Any other operation would be proxied to the nth folder (tny_header_get_folder would return the originating folder instance).

Better IMAP code

Currently the worst part of tinymail's code is its IMAP implementation code located in camel-imap-folder.c and camel-imap-store.c in camel-lite. Improvements to this code will happen continuously.

Partial retrieval improvements

Bodystructure patterns

The idea is to have a TnyMsgReceiveStrategy that gets readable parts of a message by parsing the bodystructure and selecting (using a pattern) the mime parts that are interesting.

pseudo: 

str = get_bodystructure (folder, uid)
parts = get_readable_pieces_of (str)
list = get_parts (folder, parts)
msg = make_partial_mail_with (parts)
return msg

Intelligent TnyMimeParts that do lazy loading

The idea is to have a TnyMimePart implementation that will use BODY.PEEK on the IMAP server to get itself, then cache. Rather than letting the tny_folder_get_msg(_async) get either the entire or a partial message. The tny_folder_get_msg would get a TnyMsg with bodystructure information. tny_mime_part_get_parts would create 'not yet fetched' prepared TnyMimePart instances (TnyImapMimePart or something) that will fetch themselves as soon as they are needed the first time.

Remoting, E-mail as a service on the desktop ... for many light-weight client applications

D-BUS access API

The idea is to have a remote API (in an optional libtinymail-dbus) that you can ask some questions like: give me the messages that match this query on that folder. And: give me that message's body part, its first attachment, etc.

The API would have a remote cursor for when you are dealing with large resultssets, and will keep a query result at the service's side (because at that location, it can use an intelligent mmap technique, something that's far more difficult for each client to implement).