[Chandler-dev] Bridging the gap - email options
chris at osafoundation.org
Wed Jul 19 20:12:13 PDT 2006
Sheila Mooney wrote:
> Some options for bridging the gap between the desktop and existing email
> clients that have came up so far are...
> + Emailing items to a collection on Cosmo ie: Send a /Event to
> officecalendar at cosmo.osafoundation.org
> <mailto:officecalendar at cosmo.osafoundation.org>
> + Drag and drop emails and attachments from other email clients.
> + Pull down emails that have special headers.
> + Handle a one-time import of an Inbox
> + Subscribe / Sync to select IMAP folder(s) ie: Inbox, manage design
> list in the desktop.
> + The desktop as an IMAP client
> + The desktop as an IMAP server
> + RSS in and RSS out via desktop/web access
I'd like to add to this list, if I may.
I was thinking about Travis' IMAP parcel this evening, and what a great
step forward it is. Yet setting up an imap server in the MUA is
non-trivial for many users. Even I find it cumbersome in the current
crop of GUI mailers. I also find filing messages via drag-and-drop to
be a clunky and error-prone operation.
My proposal is to extend the stamping functionality to a well-known,
cross-platform, open source MUA (I think that leaves Thunderbird),
perhaps leveraging the new IMAP server parcel.
Once the underlying infrastructure is in place, it would seem feasible
to write a simple Thunderbird extension that would add a toolbar button
to "stamp" a message as a Chandler calendar event or to-do list item.
The extension UI could be as simple as a username/password dialog,
perhaps a URL field, plus a couple of toolbar buttons. Foxmarks might
serve as a good starting point.
When a user stamps a message, the extension would add a few custom
headers to identify the content as a Chandler calendar item or a
Chandler to-do item. Then the extension would send the modified message
off to Chandler or Cosmo, via a well-established protocol (SMTP or IMAP
seem like logical choices). I can imagine either scenario, depending on
The item could then appear in an "incoming" section of the dashboard,
waiting for the user to assign whatever additional semantics are needed
for proper triaging.
In addition to preserving a simple triage workflow and GTD
functionality, there would be additional community benefits to this
approach. It would immediately attract a large audience of open source
users to the Chandler calendaring ecosystem. Foxmarks' fast-paced
growth is already demonstrating the tremendous promotional potential of
A Thunderbird extension would also demonstrate to developers of other
MUAs that meaningful integration with Chandler is possible, and perhaps
spawn community-driven plugins for Evolution, Apple Mail, Horde, etc.
I can envision a future where Chandler is the ubiquitous calendaring
server that any email client can interact with, by simply adding a few
headers and leveraging the standard protocols that are implemented in
Does this seem feasible?
More information about the chandler-dev