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- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
