Re: [evolution-patches] 57114, camel trash problems in connector




I think a cleaner way would be to do this:

- dont change get_folder, none of that code gets called unless you have a trash/junk bit set anyway
   (this patch actually breaks the logic anyway it seems, removing some stuff from the if(!folder) block)
- change get_trash and get_junk to just call get_folder(VTRASH_NAME) if trash/junk bit is set, otherwise just call the implementation.

e.g.

CamelFolder *
camel_store_get_trash (CamelStore *store, CamelException *ex)
{
	CamelFolder *folder;

	if ((store->flags & CAMEL_STORE_VTRASH) == 0)
		return CS_CLASS(store)->get_trash(store, ex);
	else
		return camel_store_get_folder(store, CAMEL_VTRASH_NAME, 0, ex);
}

i.e. unless the flag is set, it should do nothing.

Although it means get_trash behaves slightly differently if this bit it set; shrug.

The original code was supposed to abstract the trash name to be the same thing regardless of what it physically is - connector was supposed to do that.  Some of the other code assumes this is the case (in the mailer), so it will break some minor things if it isn't.  e.g. trash icon, e.g. translation of trash folder name, etc.  So keep that in mind what these changes break or complicate.


On Tue, 2004-05-25 at 13:54 -0400, Dan Winship wrote:
camel-exchange-store overrides get_trash() to return the non-virtual
"Deleted Items" folder, since that's where deleted messages go in
Exchange (and we need to override camel_store_get_trash in order for the
"Empty Trash" command to work). This makes that work again. (It also
changes get_junk to match, although we don't currently override that.)

This changes the semantics of overriding get_trash/get_junk, but it
doesn't look like it matters for any of the classes that do override it,
besides CamelExchangeStore, so I'm pretty sure that all the same locking
happens the same way with this patch as before, but the calls just
happen in different places.


Michael Zucchi <notzed ximian com>

Ximian Evolution and Free Software Developer


Novell, Inc.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]