[Design] Chandler as an email client? Another idea...

[Grant Baillie]

Hi, Morgen

An interesting idea ... some random comments are inline below.

--Grant

On Jan 13, 2006, at 15:52, Morgen Sagen wrote:

> I was thinking about where on the scale from "none-at-all" to "full- 
> blown" Chandler should be when it comes to our email  
> implementation.  It would take one heck of a Chandler email client  
> to make me stop using the application I use now.  If we have an  
> incomplete implementation that tries to be an email client, then  
> I'll probably end up dealing with email in two places (in Chandler  
> and in my other email app) which I'm not sure is optimal.  If we  
> want to instead embrace existing clients and figure out how  
> Chandler can interoperate with them, one possibility would be to  
> embed an IMAP server inside Chandler.  People could then stick with  
> their favorite email client, connected to their usual IMAP server  
> and *also* connect to the Chandler IMAP server running on their  
> local machine.

There are security issues here, of course. Hopefully, we could use  
some trick a la Google desktop to make sure we're not opening up all  
your Chandler info to the outside world. (We could make the user  
create an IMAP password, too, I guess, though that seems weird).

> What does this enable:
>
> 1) A way to get items into Chandler:  We could use IMAP folders  
> being served from Chandler itself as a mechanism to create Chandler  
> items.  Say an email comes in and I want to make a task out of it  
> -- just drag the message into a Tasks folder in the Chandler  
> account (all within my email app's UI) and Chandler automatically  
> generates a Task Item in the repository containing the body of that  
> email.  Attachments would be extracted an converted to items, etc.
>
> 2) A way to get items from Chandler to email client:  Items within  
> Chandler could appear as emails within the Chandler IMAP folders.   
> They could then also be forwarded to other people just like any  
> other email message, using your mail client.  The Chandler IMAP  
> folders could be 'virtual', meaning you could create a folder named  
> OSAF, and all Chandler items which have the OSAF tag would  
> automatically appear there.  Or there could be folders per  
> collection, etc.

This will require serializing arbitrary objects from the domain model  
as mail messages (i.e. RFC (2)822 format). Naturally, things like  
events and tasks could be represented as .ics attachments. For things  
like stamped items, you could probably do some multipart/alternative  
MIME representation that would allow Chandler to display the items in  
all their glory, while other clients would show some subset of the  
information.

Hopefully, we would not end up descending too deeply into the abyss  
of MIME interoperability :). One way to do this is to restrict the  
set of clients we would support and test against.

It's also worth remembering that messages in IMAP are immutable  
(apart from flags), so you have to make sure that changed items in  
Chandler show up as new messages (new IMAP UID, and new Message-ID  
header, probably, too). Also, if an item appears in multiple  
collections (e.g. "Tasks", things with tag "Grumpy the Dwarf"), then  
after editing in Chandler, presumably all its target mailboxes have  
to update their copies, too.

> 3) A way to generate/send email messages from Chandler:  I believe  
> it would be easy to have Chandler trigger a mail client to open up  
> a message-authoring window, complete with To: and Subject: (and  
> maybe the body too?) pre-populated, ready for the user to edit/send.

Were you thinking of doing this by asking the OS to open a mailto:  
URL? That would allow you to set headers and a plain-text body.  
Anything more complex would probably run into client bugs :).

> Or an alternative would be for Chandler to directly create an email  
> message in the local Chandler Drafts folder, ready for the user to  
> edit/send.
>
> Chandler would also continue to have (internal) IMAP/POP/SMTP  
> client support:
>
> 4) Simple emails such as sharing invitations don't really require a  
> full blown email client UI, and thus could be sent using something  
> akin to the current detail view, not using an external client.

True.

> 5) Chandler could monitor the user's real IMAP/POP inbox, watching  
> for special emails that are Chandler specific (like sharing  
> invitations) and processing them.
>
>
> My understanding is that Twisted has server-side IMAP support  
> already, so we wouldn't be starting from scratch.  This is  
> something I might tinker with...
>
> ~morgen
>
> P.S.  There are other scenarios like having Chandler actually be an  
> IMAP proxy between your email client and your IMAP server...   
> another possiblity.

I have heard IMAP server implementors say that IMAP proxies are hard  
to implement. Whether this is true in our specialized case is an  
interesting question.

--Grant