Just a quick note: I'm responding to this on the chandler-dev list to avoid the cross posting thing :)
Also, my response is to some of the technical details Chris talks about, so I figured that was a good spot for it. Briefly: I also think this would be neat, and pretty feasible. -Travis Chris Haumesser wrote: > 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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
