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

[Ettore Perazzoli <ettore ximian com>]

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

I am sorry, that was not clear at all to me.

I'd like keep the trunk working.  If we merge new-ui-branch now, then
the trunk will stop working (and not just mail will stop working,
calendar and addressbook will be in a sad state too), which might make
everyone waste a lot of time and let the trunk get out of control.

The model of not merging things until they are in a good working state
seems to have worked well so far, so I'd like to not sync new-ui-branch
to the trunk unless there is a specific reason why your code can't work
without the bulk of the UI changes.

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

I just mean a class to set up the mboxstore, initialize it the first
time, and set it up.

Maybe it doesn't need to be its own class, dunno.

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

That's what I wrote.  ;-)

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

Yeah, makes sense.  I guess it could be an account/path pair, and when
the account is not present, it means that it's in the local store?

Or maybe the local store could be an account on its own?  That could
prevent us from having to special-case the local store at all.

> > 	* 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 URIs for those folders are stored in GConf, and we need to make it
not store the home directory component of the path in that case. 
Probably we should use the same account/path pair you mentioned above.

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

Yes.

> > 	* 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?

I am a bit confused by how the vtrash code works.  Will the new
mboxstore give me a pointer to the trash just by doing
camel_store_get_trash()/?

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

Cool.  Can you get the translated name from Camel?

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

I vote for merging your code to the trunk.  This way, people who use the
trunk can start testing your code, and also we can start building new
features on top of that (e.g. anti-spam filtering) without waiting for
the new-ui-branch.

-- Ettore