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

[Lisa Dusseault]

I believe there are far easier ways of getting the exact features, and 
definitely the benefits, of what you suggest - without doing something 
so unaesthetic (and incompatible with our data model) as an IMAP 
server.

Lisa

On Jan 13, 2006, at 3:52 PM, 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.  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.
>
> 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.  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.
>
> 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design