[Design] Re: [Chandler-dev] Bridging the gap - email options
chris at osafoundation.org
Wed Jul 19 21:53:14 PDT 2006
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
> 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.
More information about the chandler-dev