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

[John Anderson]

While I think Morgen's idea is intriguing, I don't think that he's a 
very typical customer -- or if he is, Chandler's user base will be 
almost zero. Most prospective customers don't need all the features he 
does and would be quite happy with something that is an improvement over 
Outlook Express or Thunderbird. To be better, Chandler doesn't have to 
have all the same features of those products, it just needs to do a 
better job of what most people need most of the time.

John

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