[Design] Re: [Chandler-dev] Bridging the gap - email options

[Chris Haumesser]

Mimi Yin wrote:
> This would be sort of like adding a 'Chandler Toolbar' to Thunderbird, 
> in the same way there are Google, Yahoo and MSN toolbars for browsers?

Basically, yes.  What I'm proposing isn't technically a toolbar, but an 
extension.  It's a subtle difference.  If you look at the toolbars you 
mention, they're mostly just magic links to various locations on the 
web, using only the functionality that's already built into the 
browser.  Extensions are "deeper" than that, actually extending the 
functionality of the program. 

In this case, we'd have to extend Thunderbird's handling of email 
headers beyond RFC standards to add support for whatever custom header 
schema we develop (see below) for integration purposes.  There are 
probably other, more subtle bits of logic that may need to be added.

Your analogy is perfectly valid from a design standpoint.

> It would certainly make the experience of bridging the gap more usable 
> and there is already a conceptual framework for 'downloading and 
> installing' this kind of thing with toolbars for browsers, so it's a 
> plus for discoverability as well.

Precisely!  We would get the side-benefit of all the traffic to 
addons.mozilla.org!

> What's does 'setting up the infrastructure' involve?

I'm not sure if I'm the best person to speak to all of the technical 
issues, but there are a few that I can think of.  Hopefully some folks 
on the dev list will chime in to fill the gaps.

It seems like some degree of email awareness is the first step.  
Chandler already has a lot of this, while Cosmo (to my knowledge) does 
not.  The receiving end needs some way to receive and recognize a 
"stamped" email message.  We'd have to agree on a standard set of 
recognized custom headers, and implement some logic for Chandler/Cosmo 
to parse those headers and do something with them.

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



-C-