The annual "I'll change everything" report :)

[Philip Van Hoof <spam pvanhoof be>]

This is a braindump for a Tinymail 2.0. These items might or might not
happen. Given that the list of wanted changes is big, it's quite likely
that relatively few of them will actually happen (at least if I'm to
make all the changes myself).

A good technique to keep Tinymail 2.0's API backward compatible with
Tinymail 1.0's API (which is about to get released soon), is to keep me
extremely occupied.

Features:

Each message retrievals will be MIME item per MIME item. Never entire
messages anymore. You can simulate the current behaviour by requesting
each MIME part of a message.

Memory and performance improvements:

A completely new summary implementation (the mytestN.tar.gz posts)

Bandwidth improvements:

Once the new summary implementation is in place, I made implement
wave-downloading of the summary (retrieve what is visible first, the
rest at an easy pace in the background).

Support for CONVERT, for converting MIME parts to ones that are very
suitable for the screen's capabilities and the platform's filetype
support. Usually the size of the download will be smaller, so this is a
bandwidth improvement (it will cost the user less GPRS dollars).

Do pipelining here and there ... (if possible, the current IMAP code is
very not-suitable for this kind of things. So it'll be difficult). Some
things like the STATUSes could be done pipelined. Also the stopping and
starting of the IDLE state can be done pipelined.


Experimental bandwidth ideas:

Streaming media conversions! Lemonade has a specification for a media
server. This media server sends udp packets once you instruct the IMAP
server to start doing that.

Protocol implementations:

Support for NOTIFY and pick it over IDLE.

Support for ESEARCH and pick it over STATUS to get initial folder counts


UI support changes:

Threaded header views. Also interesting might be to ask for the THREAD
from the IMAP server to get hints about thread-ordering in the ui.

Grouped thread views. Group conversations together. I think this is a
lot more interesting for mobile devices than full threaded view.


API changes:

My idea on Tinymail 2.0 is to replace all boilerplate GTypeInterface
type code currently written in GObject-C with Vala code. Me and Jürg are
planning to make sure that it'll work fine to specify an API in Vala and
implement all the code in normal GObject-C code. For the interfaces I'm
planning to let Vala do both tasks. Jürg recently put design by contract
support in Vala, so this makes vala very interesting for this purpose.
It means the resulting generated C code will do exactly the same as the
existing code (Vala compiles to GObject-C code).

I'm planning to provide implementations of TnyStream for the new GIO API

I'm planning (although uncertain) to replace TnyList and TnyIterator
with Gee.List and Gee.Iterator of Vala.

I'm planning to make a libtinymail-gconf and a libtinymail-dconf as
static libraries that'll be linked with by the platform dependent ones
(libtinymail-gnome-desktop, libtinymail-maemo, libtinymail-gpe).

I'm planning to add API to TnyAccountStore for adding, removing and
altering accounts and make a TnyAccountStore observable. I'm planning to
make the TnyGtkFolderTreeModel observe a TnyAccountStore. This way you
wont have to manually remove and add account instances to the model any
more in case your user is managing his accounts. Just imlement
TnyAccountStore correctly and it'll be automatic.

Tinymail comes with default TnyAccountStore implementations in its
platform dependent libraries. I will make these easy to inherit and
extend. For example make it pluggable which configuration store is used
or make it implementable how it must interpret this. Right now Modest
for example implements its own TnyAccountStore because the default ones
were not sufficient in their functionality. The idea is to learn from
Modest's code here.

I plan to remove all synchronous API that has a Asynchronous equivalent.
I'm planning to rename all _async functions to the same name without the
_async suffix. I'm planning to provide a little wrap that will make an
Asynchronous API block until finished (using GCond).

TnyHeader is a bit of a strange name, I'm thinking about renaming it to
TnyEnvelope. Maybe, although this is uncertain and would be difficult, I
will just not expose an envelope to the API. I could also just call it
TnyMsg, and let Tinymail handle it for you when you need parts of the
message that must be retrieved. Else it would just use the envelope
parts. This would mean you'd ask a TnyFolder to give you all messages.
In reality it would just give you the envelopes first, but masked as
full messages (proxy instances). Once you touch something of the TnyMsg
that requires having the entire message, it would get it for you. The
envelope part here would be just like a MIME part (you can ask for
individual MIME parts of a message, when using IMAP). It would just be
the minimal piece of info of one message. I'm not entirely certain about
this, though. I think the application developer should be aware of
envelopes, summaries and understand the difference with a complete
message and its individual MIME parts. As a concept, it would be
interesting. Maybe a high level type on top of the envelope one and the
message one?

TnyFolder might get renamed to TnyMsgContainer, or a "container for
messages" might get introduced. The reason being that a folder is a
hierarchical type for something that contains messages. In future I
expect more flat representations to appear. A type called a container
could contain a search result too, or a type that gives message lists
based on tags.

The TnyFolder type would be just a TnyMsgContainer. One that happens to
have physical messages. In practise this comes down to moving API around
and putting an interface above the TnyFolder type.

TnyFolder itself might become an abstract type in stead of an interface
type. A lot of the functional things about a folder is sharable between
all imaginable folder implementations. It's either TnyFolder or
TnyFolderStore that'll become an abstract class. It's also possible that
I pick TnyFolderStore to be the class and TnyFolder to be the interface
(depends on how far that TnyMsgContainer will take TnyFolder). The other
one will get a pluggable default strategy-like implementation that'll be
plugged in by default.


D-Bus idea:

Have a standard D-BUS service implemented using libtinymail that'll
expose the API over D-BUS.

Have a D-BUS client implementation of libtinymail that consumes that
service (heavy use of the remote proxy pattern).

This would be mostly to get a big smile on Rob Taylor's face :)


Bindings:

For now, no drastic changes. For future I'm hoping to some day replace
the Python bindings with a PyBank based implementation. The DotNet
bindings will be working and finished and will be using Gapi2 most
likely. The Vala bindings will probably be whatever Jürg decides here.
I'm planning to throw together the skeleton for gtkmm based bindings for
C++ soon.

I might be interested in making a GClosure version of each and every
existing _async API. But most likely as a wrapper of the existing API
that wont change.

Interopability:

I'm planning to fully abstract all use of GMainLoop and provide a Qt
implementation as a proof of concept.

I'm planning to provide C++ types for each Tny type in libtinymail and
libtinymailui (abstract objects). Maybe can gtkmm help me with this.
Although one reason for C++ support is Qt. The availability of a Gtk
+/gtkmm like C++ API is of course a plus (but not my core reasoning,
mine is to have fine support for Qt that makes a lot of sense for a Qt
developer).

I'm therefore also planning to implement the models and views of
libtinymailui-gtk for Qt too, in a libtinymailui-qt.

Porting:

I'm interested in trying to port glib, gobject, iconv, pthread-win32,
camel-lite and Tinymail to WinCE and Win32. I'm also interested in doing
the same port to P.I.P.S. to make Tinymail run on a standard Symbian +
P.I.P.S. device. I'm not interested in getting Gtk+ to run on P.I.P.S.,
I'm not planning to go this far myself.


-- 
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