[Evolution-hackers] New implementation of camel_imap_folder_fetch_data

2007-01-08 Thread Philip Van Hoof
Hi there, I just finished this one, so there's probably a huge amount of bugs in it. I know I should first debug them away before posting on mailing lists ;). However, it would be nice if some (other) people would test this reimplementation (it's a method in camel-imap-folder.c, by the way).

Re: [Evolution-hackers] New implementation of camel_imap_folder_fetch_data

2007-01-08 Thread Philip Van Hoof
Bweachrgg. It seems camel_imap_command_response performs an extra CAMEL_SERVICE_REC_UNLOCK (store, connect_lock) (for some reason, I can't figure out why that it is like that, but ... ). And it looks that the code calling camel_imap_folder_fetch_data assumes that this unlock happens (at least at

Re: [Evolution-hackers] New implementation of camel_imap_folder_fetch_data

2007-01-08 Thread Philip Van Hoof
Ah, I figured it out. The camel_imap_command_start places the lock, and the functions that are usually used with the results unlock it. owk. * On success, the store's connect_lock will be locked. It will be freed * when you call camel_imap_response_free. (The lock is recursive, so * callers

Re: [Evolution-hackers] New implementation of camel_imap_folder_fetch_data

2007-01-08 Thread Philip Van Hoof
So, after the lock fixes and a few other bugfixes, this is a new implementation. I left the partial-retrieval thingy in place. Just remove the full parameter from the function and comment the else part of the if (full) { } else { } thingy to use it in a normal Camel. static void handle_freeup