A new development branch for the bodystructure work, the begin of Tinymail 2.0

[Philip Van Hoof <spam pvanhoof be>]

-== New branch for BS

The BODYSTRUCTURE branch implements true BINARY support and fetching
parts as they are needed (in stead of entire E-mails).

It's not just in experimental stage. It actually works.

http://svn.tinymail.org/svn/tinymail/devel/pvanhoof/bs/

I still have to re-implement tny_mime_part_set_purged,
tny_msg_rewrite_cache and tny_msg_uncache_attachments.

To implement set_purged I will most likely move the files to a "purged/"
subfolder and write an empty placeholder file in the original folder. I
will most likely provide a BS specific unpurge API. I will most likely
rewrite the cache of a message by clearing its files in that "purged/"
directory.

-== How I envision Tinymail's development future:

TODO for Tinymail 1.1:

 o. Cleaning up code, cleaning up code and again cleaning up code

 o. Porting fixes and cleaning up to Tinymail 2.0

 o. Staying API and ABI compatible with Tinymail 1.0

 o. Writing (more) unit tests (when created they will indeed be added to
    1.1, not just to 2.0. Except when they test a 2.0-only API).

 o. Writing documentation. This wont change API when clarifying 
    something that used to be vague: The 1.1 documentation must
    document 1.1's real behaviour. Not its expected behaviour unless
    the real behaviour and the expected behaviour are the same (the
    normal case, I hope).

    2.0's documentation, while 2.0 is not released, however, must
    document expected behaviour regardless of what the real behaviour
    is.


TODO for Tinymail 2.0. I see this BS branch as the first steps towards
this new version. Even before releasing 1.0, as I have been slowly
feature freezing Tinymail 1.0 (the release is taking too long, we need
to start working on new features or we'll stall development too much).

 o. Implementing purging of attachments in TnyCamelBsMimePart and
    TnyCamelBsMsg

 o. Testing the bodystructure parser against a lot of awesomely strange
    messages, for example testing its parse error reporting capability.

 o. Either rename TnyMsgReceiveStrategy to TnyMimePartReceiver, leave it
    as it is or create a new type TnyMimePartReceiver and split up the
    TnyCamelBsMsgReceiveStrategy into two classes ("be one thing, do it
    very well, and don't try to be anything else")

 o. Rename TnyHeader to TnyEnvelope (which is much more right given IMAP
    refers to these header fields from the MIME part as the ENVELOPE).
    IMAP is our primary target, so this makes sense in my opinion.

 o. Getting rid of tny_header_get_uid, replacing it with an API that can
    provide both the uid and the part_spec and that can be NULL for
    non-remotely stored items (for forwarded messages, the TnyHeader
    could have a uid, but that uid is meaningless: its uid plus the
    part_spec, however, correctly identify the item on the IMAP server
    precisely)

	o. My  current idea is to have two interfaces:

	   - TnyEnvelope which will have just the ENVELOPE items
	     and maybe the uid_spec too (not sure about this yet).

	   - TnyHeader which will inherit TnyEnvelop and will have
	     a uid too.

	o. Five Implementations:

	   - TnyRFC822Envelope for forwarded messages
	   - TnyCamelEnvelope (one that proxies a CamelMessageInfo)
	   - TnyCamelHeader inherits TnyCamelEnvelope
	   - TnyCamelMsgEnvelope (one that proxies CamelMimeMessage)
	   - TnyCamelMsgHeader inherits TnyCamelMsgEnvelope


Features for Tinymail 2.0 that I want:

 o. CONVERT. Once the BS branch is fully tested and working nicely, this
    should become easy to implement.

 o. GTypeInterface boilerplate code -> Vala interfaces

 o. Using the GIO stream interfaces in stead of TnyStream

 o. A DConf configuration store (as a static library)

 o. Making a static library for:
	o. The default sample GConf TnyAccountStore
	o. The NetworkManager TnyDevice
	o. A HTML TnyMimePartView based on Gecko
	o. A HTML TnyMimePartView based on Webkit
	o. A HTML TnyMimePartView based on GtkHTML

 o. Those static libraries will be optional when linking with your
    libtinymailui implementation (for example libtinymailui-gtk).

 o. Right now these are shared object files, shared object files for
    small pieces of code, add a small overhead in memory consumption.
    Therefore I would prefer these to become static ones (this is mostly
    build environment adaptations, adding some more flexibility).

I'm not sure about this:

 o. I want to extend the TnyAccountStore interface to require the
    application developer to implement adding and removing accounts. The
    default implementations will of course have to do this too then.

    The reason for this is that we also have a TnyAccountStoreView
    interface in libtinymailui (which is probably unused, except by
    TMut, but oh well): we could require the implemented of a
    TnyAccountStoreView to cope with addings and removals of accounts
    and that way make TnyAccountStore a model like any other (observable
    by the view). TnyGtkFolderStoreTreeModel could then for example
    implement this interface.. and cope with that automatically
    (whoohoo! less code in your E-mail client!)


Final note. I understand as Modest is being released, most developers
will focus on Tinymail 1.0 for a few more weeks (maybe months). I hope,
however, that interest in the Tinymail 2.0 work will grow somehow.

I will try to make migration paths to a new API as painless as possible.


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