[Evolution-hackers] Mailer and new-ui-branch

[Ettore Perazzoli <ettore ximian com>]

Hello!

So, now that the Mozilla-like folder store seems to be getting in good
shape (thanks Jeff!), we can get the mailer on the new-ui-branch to
actually work with local mail again.

The current state of mail/ in new-ui-branch is:

	* Last synced with HEAD 1.5 weeks ago (I'll do another merge
          as soon as the refactored front-end code gets merged in).

	* All the EvolutionStorage stuff has been nuked.  Everything
          is done internally with EStorages instead, and displayed
          with an EStorageSetView that gets exported to the shell as a
          control (EStorages have virtually the same API as
          EvolutionStorages, the code hasn't actually changed much).
          The shell is no longer involved with folder tree management,
          unread counts etc.

	* Since there is no more local storage, all the mail-local.c
          is no longer hooked up, and there is no "Local Folders" node
          in the tree.  However, IMAP configured accounts work as
          expected.

	* (Some other stuff is unfinished, e.g. no icons, and no
          vfolders.)

Now, the next step is to reimplement the local storage code around a
single CamelMboxStore that handles the whole hierarchy of mail folders
within the mailer, using Jeff's new code.

After doing some reading through the mail code, I think these are the
things that need to be changed to get there:

	* As part of the component's initialization, set up a stock
          local mbox store, with a root in ~/.evolution/mail/local.
          When run the first time, we add the stock folders there as
          subfolders (Inbox, Drafts, etc.).  There should probably be
          a new class to handle the local store, although I am not
          sure what name it should have with the new naming
          conventions.

	* Register the store the same we register the other
          account-driven stores (i.e. like IMAP).

	* Change mail_tool_get_local_inbox() so that it points to the
          stock Inbox we created in the local mbox store.

	* Make the drafts_folder, sent_folder, outbox_folder globals
          point to the appropriate folders in the mbox store.  (And
          once this works, replace the globals with proper methods on
          MailComponent, or wherever it makes sense.)

	* Since the format of the physical folder URIs is going to
          change, it's probably a good idea to tweak the filter code
          so that it uses a relative path for local folders instead of
          the full blown URI, while we are at it.  (This is to avoid
          the well-known problem with users moving data between home
          directories with different pathnames.)

	* In a similar way we should fix the code that handles the
          default folder URIs (i.e. those for "Drafts", "Outbox",
          "Sent").

The things I am not so sure about:

	* Shouldn't we add knowledge to the camel store about where
          the inbox is?  I.e. shouldn't camel-mbox-store.c implement
          get_inbox()?

	* Should we move the whole vtrash implementation to the mbox
          store as well?  This might simplify things in the code a
          bit, and also give a hook for 3rd party apps.  I am not sure
          how much work this would be.

	* How do we handle the translation of stock folder names?  We
          need the names of the "Inbox", "Drafts", "Outbox", "Sent"
          folders to be translated in the user's language.  We can do
          it with EStorage/EFolder (as the shell did it before), but
          then, again, that information won't be visible at Camel
          level.

Any other things that you can think of?

While I am at it, we are also going to need to write a tool to migrate
an existing Evolution setup into this new one.  We also need it soon,
so we can use it for testing the mailer on new-ui-branch before we
merge the code to the trunk.

The tool should be able to:

	* Traverse ~/evolution/local and copy the structure into the
          new Mozilla-like format.  Of course, there are cases that
          won't translate directly, but they are going to be rare and
          can be dealt with pretty easily.  E.g.

	  	Mail Folder #1
			Contacts Folder
			Mail Folder #2
		  	Calendar Folder
				Mail Folder #3
				Mail Folder #4

	  can be turned into:

	  	Mali Folder #1
			Mail Folder #2
			Mail Folder (uses name of prev. Calendar Folder)
				Mail Folder #3
				Mail Folder #4

	* Translate the URIs in vfolder.xml and filters.xml into the
          new format.

We could initially write this as a command-line tool and make it part
of the actual upgrade process later, once we dust has settled down a
bit.

Thoughts?

-- Ettore