[Evolution] merged notzed-messageinfo-branch

[Not Zed <notzed ximian com>]

Dunno whats wrong with the mailing lists, but re-sending again.


Hi guys,

I'm just about to commit the changes from the notzed-messageinfo-branch back to head.

The main results of this should be:

• less memory use
• much faster trash and junk folders
• some bugs fixed (like junk unread being counted in source folders)
• nothing _should_ break.

So keep an eye out for weird breackage type things, but i'm fairly confident there will be no problems, I have been using it for the last few days without any.  IMAP and IMAP4 are less tested though, and the Exchange code isn't tested at all, so i'm sorry if i broke anything there, nothing should be too hard to fix though.

On the technical side, a couple of things have changed which any developers of providers need to be aware of.

CamelMessageInfo

This structure has shrunk to only 3 values, a parent pointer, which points to the parent CamelFolderSummary - if this is NULL, a default implementation is used and the messageinfo is a folder-less one, a refcount, and the uid.  All values are now accessed through accessor methods on the summary itself.

Any subclasses of camel-folder-summary can just subclass this basic content-less messageinfo, if they don't want to do any i/o.  Otherwise they need to subclass CamelMessageInfoBasic, which also contains the basic values.  All client code must use accessors to access the fields now.

Strictly, I should have subclassed CamelFolderSummary again for this 'basic' type, but this ends up with the same result with fewer changes externally - unfortunately it does make some of the classes behaviour 'non obvious to the outside world', at least on first glance.  This is a bit of a messy thing, so it might need tweaking, but for now it works fine.  It probably needs some documenting.

Finally, all of the strings in the summary are now in a new, much simpler, string management interface.  Instead of the poolv or strv stuff which is fairly complex and not ref-counted, there are 2 new calls, one to allocate a 'static' string, and one to 'free' it, this unique-i-fies all common strings into a single pointer value, and also refcounts the allocations which wasn't done before.  This may make a slight difference to memory use, at least over the long term.  I'll remove EPoolv/EStrv soon, they should no longer be needed at all.  The new interface is in camel-string-utils.h and could be used anywhere where strings could/should be uniquefied (i.e. where duplicated strings is likely, even e.g. tag names, although that isn't done yet).

CamelFolderSummary

Now has many more virtual methods, these are used to access the camelmessageinfo fields.  If you need to provide your own implementation of CamelMessageInfo, then you can't do the i/o stuff, and need to override most of these virtual methods.  In reality only vFolder type implementations need to worry about this.

Another big change is that the summary now emits the folder-changed events on the parent folder which it also now has a pointer to.  This reduces most of the duplication that was in CamelFolder to handle setting of flags/etc, and also simplifies the use of camelmessageinfo's in the code.  We just set flags and tags on the messageinfo directly, and if it happens to be associated with a folder, the changes happen on the folder directly.  We don't need duplicated api's or duplicated implementations.

Some of the api's have been removed or slightly renamed, so there isn't duplication anymore.  e.g. camel_folder_summary_info_new() has been replaced with just camel_message_info_new(), camel_folder_summary_info_free() has been replaced with just camel_message_info_free(), etc.

CamelVeeFolder

Now has a few virtual methods which lets subclasses implement virtual folders which use differnet query engines.  The summary changes mean that VeeFolder nodes now use MUCH less memory.  They are also true virtual messages, that is, they don't copy the flags and tags and subject and all that, they indirectly reference the real values.  This makes certain operations a little faster, since changes do not need to cascade through as many levels to reach the UI.

CamelVTrashFolder

Now uses custom code to implement, so it is MUCH faster.  This should noticably affect mailer startup time, particularly if you switch from another component.

CamelFolder

A bunch of api's are now deprecated or removed.  e.g. camel_folder_message_info_free() is deprecated in favour of camel_message_info_free().  camel_folder_set_message_user_flag() is deprecated in favour of camel_folder_get_message_info() followed by camel_message_info_set_user_flag(), etc.

The deprecations could and probably will be removed very soon since its only an internal library and there's no need to keep them around for any period of time, I just wanted to make the changes relatively managable and get it into HEAD before the code diverged too much.  Since you can have folders without a summary interface, such as pop, then i will need to add in an explicit delete_message method, but i envisage all other message-state setting to only go through the 'summary' interfaces in future.

Cheers,
Michael

--

Michael Zucchi <notzed ximian com> "Free Software, putting the Free back in Free Market." Novell's Evolution and Free Software Developer