Re: [Evolution-hackers] posting to folders

[Not Zed <notzed ximian com>]

On Tue, 2004-05-25 at 10:50 -0400, Dan Winship wrote:
> On Tue, 2004-05-25 at 10:16 +0800, Not Zed wrote:
> > > > Well the main problem here is we're going to have to use the folder in
> > > > most cases anyway - because users want their damn folders to update
> > > > immediately when they move messages around.  If we're just updating 'a
> > > > bit later on' we'll get bug reports.
>
> But if the folder isn't open yet, all you need to worry about is the
> unread count. You don't actually need to update the summary until the
> user goes to look at the folder. So for things like the Sent folder, or
Hmm, I guess.
> filtering messages into a folder you only look at rarely, or moving old
> messages into an "archive" folder, this would save time.
>
> > > > And for move between imap
> > > > folders on the same folder, its much better using imap copy. 
>
> Yeah, you'd use imap copy anyway, you just wouldn't look into the
> destination folder first like we do now.
Except this api wouldn't allow this, since its message -> folders, not folder + uids -> folder(s).  It would need Jeff's idea of folder open state, and just use the existing api.
> > I don't think this would make sense unless we just got rid of
> > CamelTransport entirely and just having it as virtual methods and
> > capability bits on CamelStore?  Could this simplify the store is also
> > a transport issue?(or if we had interfaces on camelobjects and did it
> > that way instead).
>
> Hm. Where would the sendmail and smtp code be in that case?
Same basically, they'd just be 'mostly unimplemented' stores.  Ideally it would be an interface on the object, but at the end of the day it wouldn't make much difference if it was just a virtual method and a bit to say it doesn't work.  On the other hand this is post 2 stuff, and i had most of an interface system done anyway at one point, so that could be possible too, it could clean up some other stuff too.
> Merging store and transport would definitely make the Exchange transport
> nicer though. (Currently it pretends to do POP-before-SMTP auth so that
> evo-mail will give it a copy of the exchange store URL which it then
> uses to get a copy of the CamelExchangeStore object.)
Wow.  Well that was the primary goal of the idea; and it seems a natural abstraction for stores anyway.

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer

Novell, Inc.