A new development branch for the bodystructure work, the begin of Tinymail 2.0
- From: Philip Van Hoof <spam pvanhoof be>
- To: tinymail-devel-list gnome org
- Subject: A new development branch for the bodystructure work, the begin of Tinymail 2.0
- Date: Wed, 28 Nov 2007 00:37:32 +0100
-== 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]