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

[Not Zed <notzed ximian com>]

On Mon, 2003-09-15 at 13:18, Ettore Perazzoli wrote:
> 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).

You mean the mail refactor branch?  I was actually waiting for the new-ui branch to be merged first.  Then both Jeff and I can fix the mailer up from there, and you can work on finishing off whatever is needed in the shell.

> 	* 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.
Isn't this what jeff's mboxstore is for?  Isn't the whole point not to have another mail-local (which is a store wrapping a camel store with different path semantics).

> 	* Register the store the same we register the other
>           account-driven stores (i.e. like IMAP).
i.e. same here.  no difference for the mbox store vs imap or maildir, etc.

> 	* 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.)

a function isn't any less global than a global.

> 	* 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.)
The filter code shouldn't know anything more than a uri.  If the local uri's are to become relocatable it has to be done at another level.  e.g. by some account-name-based indirection to the store, then a folder path off of that.

> 	* In a similar way we should fix the code that handles the
>           default folder URIs (i.e. those for "Drafts", "Outbox",
>           "Sent").
By ... (as bove)
	* 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.)

Or do you mean something different, i.e. a made up evolution:/Drafts idea?

> 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()?

You mean, ... camel_store_get_inbox(), right?

> 	* 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.
No.  I don't understand this actually.  What do you mean?

> 	* 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.
We will simply do it the same way we do Unmatched.  Camel has a standard name, which can be translated for display purposes (only).  It shouldn't be visible at the 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?

Well i was kind of hoping you would merge in the new ui branch to head, and then Jeff and I could then merge that into our branch/merge our branch in, and clean everything up to a working state.  Or we could merge your code into our branch and fix it up before merging into head.  Or we could merge our branch into your branch and work on it from there, i'm not that fussed.  Otherwise we'll be blocking on your branch work.