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

[Not Zed <notzed ximian com>]

On Mon, 2003-09-15 at 23:49 -0400, Ettore Perazzoli wrote:
> 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.
Hmm, communication lacking again.  I thought i mentioned it on irc, i definetly asked you when you were merging back to head, but you told me when you were merging from head intead.

> 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.
I think we'll waste a lot of time making code work that is going to vanish.  But whatever, you're the boss.

> 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.
Umm, its worked so well since we haven't actually merged anything back?

> > > 	* 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.
It doesn't.  There is other non-related setup that also needs to be done at that time anyway, it would make sense to put it together.

> > > 	* 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.  ;-)
yeah, but you wrote it like it meant more owrk, but its for free.

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

the problem with this is that it isn't that trivial to write.  its quite a big task, and would potentially affect account editing, etc.

> 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.
yeah, thats the idea.

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

that would be the cleanest way, but it depends on how practical it is.

> > > 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()/?
It should, if it doesn't it just isn't finished yet.  Thats what abstraction is about, abstracting the details of shit like that away from the callee.

> > > 	* 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 camel wont, but you could get the string camel will use as a standard string that you can then translate externally.
i.e. exactly the same way unmatched works.

> > 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.
Ok, your 1 vote wins I guess ...

Anyway, I'll try to get it merged in by the end of the week now i've been told.

As for anti-spam stuff, we never came up with a concensus on that.  You want to tightly couple with spam-assassin, nobody else seems to think that's a long term solution.  It doesn't address server-applied spam filtering headers.  Jeff and I would like it to be pluggable.  You want a dumbed down ui anyone can use, I can't see how that can work without us doing our own system, and/or tightly coupling with a very specific version of some other tool, etc.