[Chandler-dev] Thunderbird / Exchange and Data flow in to Chandler

Jonas Beckman jonas.beckman at indra.se
Tue Jan 8 12:44:34 PST 2008


Connecting to Thunderbird and/or Exchange certainly sounds
like very good ideas! A Chandler plugin for Thunderbird with some of the 
suggested features would be a straightforward way to leverage
lots of existing email functionality, for those who need that.

It's always dangerous to extrapolate too much from one's own
experience - but the lack of these two things has been keeping
at least me from using Chandler as a primary PIM. I manage a variety of
POP3 and IMAP email acconts with Thunderbird. And for professional
reasons - and because it gives me decent mobile syncing - my calendar,
tasks etc live on an Exchange server.

I believe many (perhaps the majority of?) future Chandler users would 
prefer not having to abandon existing email/calendar solutions, but 
rather integrate in different ways. And I think this is especially true 
for those who need Exchange/Outlook data at work.

For Exchange, I agree that short term the Python/COM route via Outlook
is probably the quickest alternative. Having done similar things with 
both SQL Server and Excel in the past, let me just note that error 
handling and performance tuning can take far more development time than 
the basic functionality for demanding use cases.

To developers who prefer Mac and Linux (like many of us) a serverside
Exchange solution has obvious appeal. But is the option to integrate
with Echange from other platforms a big attraction to many potential 
users or irrelevant to most of them? I have no idea. By the way, does 
anyone have download statistics for various platforms so far?

Jonas

> 
> There are a number of aspects of Open Change that I think
> makes it not an ideal project to tackle right now.
> 
> First. it has a GPL license which makes it incompatible with
> Chandler's Apache license. There are certainly ways to work
> around that however, the major draw back of using Open Change
> for Exchange connectivity is its huge dependance on Samba.
> 
> Open Change is really intended to provide Exchange connectivity
> to the Unix platforms. The proof of concept project that Open Change
> is working on is an Exchange  plug-in for the Linux Mail Client Evolution.
> 
> I believe not being able to provide support for Windows users who
> are the ones mostly using Exchange in a corporate environment
> is less than ideal.
> 
> One option is to create an Exchange to Chandler Proxy Server
> that could handle data transformation between Exchange MAPI and
> Chandler CalDAV / EIMML.
> 
> Again it would be limited in terms of the platforms it can deploy on
> due to the Samba dependency.
> 
> Either way, the investment costs to implement the Exchange
> connectivity via Open Change will be high and probably not worth
> it at this stage of the Chandler project.
> 
> I do have another suggestion which although still not ideal can deliver
> a credible Microsoft Outlook / Exchange story in a much shorter development
> window using tools already available in the Python community.
> 
> It would be pretty straight forward to leverage Python the Win32 bindings
> (http://sourceforge.net/projects/pywin32/) to connect via COM to the
> Outlook Application Object and via MAPI retrieve Calendar / Scheduling / 
> and
> Tasks from an Exchange server.
> 
> The SpamBayes project already has a successful Outlook Plugin written
> in Python for Spam Classification so we can leverage the general 
> principles they
> employ.
> 
> The specifics of what operations would be performed when connecting to
> Outlook / Exchange as well as whether the functionality would be an Outlook
> or Chandler Plugin are still open to debate.
> 
> But in a fairly fast development window Chandler could in this scenario
> provide a means for Outlook / Exchange users to bring data in to Chandler.
> 
> In fact, the Outlook Plugin and the Thunderbird plugin could provide the 
> same
> feature sets.
> 
> The limitations of leveraging COM to connect to Exchange are:
> 1. It's Windows Only
> 2. The User has to Have Outlook Installed on the System
> 
> 
> Thoughts /  comments / alternative suggestions about Exchange next steps?
> 
> -Brian
> 
> 
> Brian Kirsch
> Internationalization Architect / Mail Service Engineer
> Open Source Applications Foundation
> 543 Howard Street 5th Floor
> San Francisco, CA 94105
> http://www.osafoundation.org
> 
> 
> On Dec 7, 2007, at 1:30 PM, mimi at osafoundation.org wrote:
> 
>> Brian Kirsch and I met briefly today to brainstorm re: email/SMS 
>> integration ideas we can pursue in the short and mid-term. The goal is 
>> to find ways to improve getting data in and out of Chandler to mobile 
>> devices and other mail applications, in particular Thunderbird.
>>
>> Here's the beginning of our list of ideas. Please add your own!
>>
>> Mimi
>>
>> Sync messages in IMAP Drafts/Sent folders with Chandler Drafts/Sent 
>> messages.
>>
>> Use SMS / Email to:
>> + Add items to a collection(s) on Hub Service
>> + Pull items from Hub Service
>> - Today or Some day's events
>> - Today or Some day's tickled items
>> - NOW items in a particular collection
>> - Particular item in a collection
>>
>> Ideas for Thunderbird Plug-in:
>> + Stamp a message and add it to a list of collection(s)
>> + Assign Triage status to message items
>> + Map individual IMAP folders to collections
>>
>> Receive notifications from Hub Service in T-bird or via Email/SMS
>> + # New / Edited items in which collections
>> + Who last updated an item/collection
>> + Stuff that's tickled into NOW
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
> 
> 
> 
> 
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
> 






More information about the chandler-dev mailing list