[Chandler-dev] Chandler thunderbird extension (Was: Bridging the gap - email options)

Travis Vachon travis at osafoundation.org
Thu Jul 20 15:30:34 PDT 2006

Just a bit of a braindump on this idea:

> Next, there are transport considerations.  The first decision is where
> to send the data: Cosmo, or Chandler?  This will largely affect how
> the data is transferred, e.g. what protocol to use.  This is likely to
> be a matter of significant debate, and I predict that ultimately both
> Chandler and Cosmo would want to support a common email/header API,
> but perhaps over different transports.  Chandler might leverage its
> growing IMAP support, while the hosted service might end up using SMTP.
As it stands the Chandler IMAP server runs with some pretty standard
settings (that is, a set username, password, and port). This could lead
to a "quick setup" button which would automatically set up an IMAP
account pointing to Chandler, and would aid in the creation of an "add
to Chandler" button.

As I see it, a Chandler aware Thunderbird extension would work like this:

1) When a mail item is "stamped" in Thunderbird, Thunderbird would do
one of two things:

     a) Thunderbird adds the stamping information in custom e-mail
headers to the underlying representation used by Thunderbird. This would
probably be possible with POP, but might be REALLY tricky with IMAP.


     b) Thunderbird leverages the "add to chandler" functionality to add
headers and send them to chandler in one step. This would make it
difficult to stamp something in Thunderbird more than once and
experience the desired behavior (that is, an update of the Chandler item
upon Thunderbird stamping).

The important thing is that when a message is sent to an IMAP server
(via drag and drop to the server's folder in Thunderbird or the send to
chandler button) this information is included as header information.

This actually might be a very hard problem in Thunderbird, depending on
what kind of access to internals/ message representations is available
to the extension framework.

2) When a message is dropped into Chandler's IMAP folder, the header
information would go with it. When messages with these special headers
are received in Chandler, Chandler would know what to do with them. This
would also need to be implemented into the mail handling mechanisms of

> As I see it, those are the main technical issues to be hashed out
> before work on an extension can go very far.  There are undoubtedly
> people who know more than I do about this, and I hope they'll help me
> out.  :-)  The issues certainly aren't trivial, but don't seem
> insurmountable to my (ignorant) eyes for the 1.0 or even beta time frame.
There are definitely some tricky issues, foremost among them (in my
eyes) making Thunderbird support the addition of extra headers in some
form (whether via immediate transport or storage in the underlying
message representation.

If I had to guess, I'd say this probably wouldn't get done in the beta
timeframe by someone in the core development team, but it seems like it
would make a fantastic community or Summer of Code project for someone
with some existing Thunderbird extension experience. It _would_ be
pretty neat functionality : )

> -C-
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev

More information about the chandler-dev mailing list