Writing a GNOME mail client.

[Miguel de Icaza <miguel nuclecu unam mx>]

Hello guys,

   So, I was watching the grass grow the other day, and it ocurred to
me that the main medium of communications for the free software
community is mail.  Is it our most valuable communication resource.
Still I have not seen any mail program which is truely powerful,
extensible and it is designed to address the needs of our community. 

   The mail needs of people these days are rather different from those
some years ago: keeping up with high-volume mailing lists; keeping up
with important people; being able to keep track of conversations;
being able to easily archive messages based on various criteria; being
able to automatically split mail in folders; being able to decode mime
messages and render them nicely; being able to link the addressbook
with corporate address book services; schedule appointments. 

   So we need to provide this powerful tool.  Now, given that the core
of Gnumeric took only two months to develop and it was a rather solid
and good piece of code, I am confident that we can tackle this project
as well and do things right. 

   Now, what do we need to make this a reality?  Well, step number one
is to make this project fun and reusing all of the nice code and
infrastructure that we have developed over the past months.  

   Given that we are going to redo the Mail application for GNOME, I
have a number of ideas on how to do this.  So this is sort of a call
for volunteers that want to start working on such a beast.

   We need various modules in this mail program.  Each module should
be implemented as a CORBA object, exclusively because it allows us to
upgrade different components and choose different implementations over
time, without having to update the whole system.

   Contextual operations are very useful, so we should use Button-3
for context operations as much as possible.

* Mail storage 

   This will handle the handling of the mail input backend, supporting
   various existing setups: imap, pop, spool mail, Mailbox, MH. We can
   steal the design for the interface from GNUS.

   The mail storage should provide the mail splitting: applying all
   the rules defined for separating the mail into different folders. 

   See [1] for more information. 
      
* Summary display

   Summary display should allow people to list the messages in a
   folder.  We should implement what most people expect from the
   folder summary display, but on top of that we need that right
   clicking on a message presents useful options about the message: 

	a. Increase the score for this author/thread.

	b. Use this message as a "pattern" for automatically
  	   creating a new folder.

	   So that users do not end up editing manually their
           .procmail file, nor using a GUI to manually wonder
  	   which header needs to be used for splitting.

	   We can get splitting right most of the time, so by
           default we should be ablt to do a pretty good job.

	c. Allow the user to auto-archive any conversation with the
	   person selected or to auto-archive a thread (ie, based on
           Subject). 

   It should be possible from a message to see what the guy is
   replying to with a single click.

* Message Display

   This should be clearly a full fledged display engine for all of the
   new stuff we get on the net these days.  Integration with Bonobo for
   displaying message contents would be excellent.

   We can use Mozilla to render the display in the future, so a simple
   renderer for now would do the job. 
   
* Tool integration

   I suggest that the Message Display engine be decoupled by a clean
   CORBA interface from the Summary engine and from the folder
   engine.  

   We should integrate not only this, but it should integrate
   seemlessly with the calendar and the addressbook (the addressbook
   needs to be redesigned, because currently it is: not powerful and
   not very nice).

   The actual tools can be embedded with Bonobo (we can bootstrap with
   this feature turned off, but eventually it will be like this), so
   it will look like a big unified interface to the end user.

* Why not improve an existing mailer program

   There is too much baggage in existing mail applications that we do
   not want to carry into the future.  Reusing parts of existing GPL
   applications and mail applications should be fine, but I do not
   think there is much to be rescued.

   I would love to be proved wrong on this topic.  But the experience
   of gnumeric has left a very good taste in my mouth: it is possible
   to do so and it is possible to do this in a very clean fashion. 

* Developing this mail client

   We need to split the work between hackers.  Each one choosing a
   very specific task, so that we can paralellize as much as
   possible.  

   Cordination will take place on the gnome-mailer-list@nuclecu.unam.mx, 
   to subscribe send mail to gnome-mailer-list-request@nuclecu.unam.mx
   and put "subscribe" as part of your message.


[1] Bertrand has been working in such a beast, perhaps we can reuse
   some of his code.  I am just a bit concerned that the
   implementation is in Objective-C, which means that people need an
   objective-c compiler on their system to compile it.