Re: [Evolution-hackers] camel local provider and Bug 213072

[Seb James <seb esfnet co uk>]

On Tue, 2007-01-16 at 05:44 +0100, Philip Van Hoof wrote:
> Hey Seb,
> 
> Thanks for your interest in wanting to improve Camel. Multiple projects
> would benefit from your contributions, so I'll explain how you can
> implement what you want to try to do (not sure if your specific feature
> makes a lot sense, but nevertheless is it good that you are at least
> reading code in stead of just whining feature-requests, right?) :-)

Hi Philip,

Many thanks for your reply!

I agree that it is good sense for you to explain how e-d-s works even if
my feature doesn't make sense. As I get a better picture if the design
of e-d-s, then I might well come to that conclusion myself ;)

There has been some talk about the fact that many free software projects
are comprised of very small, somewhat static teams, rather than the
utopian idea of many eyes. 

It takes a _lot_ of effort to learn the architecture of a complex
project like evolution, even if you have been writing code for some
years, so helping new developers must be important to keep a project
vibrant.

So, why am I looking at message expunging in the mail spool?

Well, I believe that the contents of the spool is causing the error
described in Bug 213072. Particularly, I think the problem occurs when
the contents of the spool file is changing often, or at least changing
for an extended period. For example, when fetchmail pulls my mail in, it
might take five minutes to download it and process it all through
mailscanner (I subscribed to lkml to exacerbate the problem I am
having).

I believe (but it's a theory right now) if e-d-s is performing a sync at
this time, it gets confused, with the error message saying that the
position of the message stored in info->frompos is different from the
one measured by camel_mime_parser_tell_start_from().

So, I was looking at the spool file, and noticed that deleted messages
aren't expunged, and wondered why that is.

Using the unix spool as inbox, there appears to be no mechanism for
these deleted messages to be expunged. I wondered if e-d-s is supposed
to be expunging them and failing.

So, do you think it makes sense for e-d-s to expunge messages from the
unix mail spool?

Thanks again for the explanation you gave, it's very helpful!

Seb

> Because CamelSpoolFolder (camel/providers/local/camel-spool-folder.c)
> does not implement it, it's going to be the default expunge of
> CamelLocalFolder (camel/providers/local/camel-local-folder.c). That's
> the case because the CamelSpoolFolder inherits the abstract
> CamelLocalFolder type. 
> 
> Else it would have been the default implementation of CamelFolder, which
> would just print a warning that it's not implemented (camel-folder.c)
> 
> 
> These are the current methods being implemented by CamelSpoolFolder:
> 
> static void
> camel_spool_folder_class_init(CamelSpoolFolderClass *klass)
> {
> 	CamelLocalFolderClass *lklass = (CamelLocalFolderClass *)klass;
> 
> 	parent_class = (CamelFolderClass *)camel_mbox_folder_get_type();
> 
> 	lklass->create_summary = spool_create_summary;
> 	lklass->lock = spool_lock;
> 	lklass->unlock = spool_unlock;
> }
> 
> 
> static void
> local_expunge(CamelFolder *folder, CamelException *ex)
> {
> 	d(printf("expunge\n"));
> 
> 	/* Just do a sync with expunge, serves the same purpose */
> 	/* call the callback directly, to avoid locking problems */
> 	CAMEL_FOLDER_CLASS (CAMEL_OBJECT_GET_CLASS(folder))->sync(folder, TRUE, ex);
> }

I did wonder if this was the way that trashed messages were expunged,
but I'd not found this local_expunge() function.

> The sync function pointer will resolve to this implementation:
> 
> static void
> local_sync(CamelFolder *folder, gboolean expunge, CamelException *ex)
> {
> 	CamelLocalFolder *lf = CAMEL_LOCAL_FOLDER(folder);
> 
> 	d(printf("local sync '%s' , expunge=%s\n", folder->full_name, expunge?"true":"false"));
> 
> 	if (camel_local_folder_lock(lf, CAMEL_LOCK_WRITE, ex) == -1)
> 		return;
> 
> 	camel_object_state_write(lf);
> 
> 	/* if sync fails, we'll pass it up on exit through ex */
> 	camel_local_summary_sync((CamelLocalSummary *)folder->summary, expunge, lf->changes, ex);
> 	camel_local_folder_unlock(lf);
> 
> 	if (camel_folder_change_info_changed(lf->changes)) {
> 		camel_object_trigger_event(CAMEL_OBJECT(folder), "folder_changed", lf->changes);
> 		camel_folder_change_info_clear(lf->changes);
> 	}
> }
> 
> 
> 
> If you want to implement a specialised version for "spool" folders, fill
> in the function pointer like this:
> 
> static void
> camel_spool_folder_class_init(CamelSpoolFolderClass *klass)
> {
> 	CamelLocalFolderClass *lklass = (CamelLocalFolderClass *)klass;
> +	CamelFolderClass *camel_folder_class = CAMEL_FOLDER_CLASS(camel_local_folder_class);
> 
> 	parent_class = (CamelFolderClass *)camel_mbox_folder_get_type();
> 
> 	lklass->create_summary = spool_create_summary;
> 	lklass->lock = spool_lock;
> 	lklass->unlock = spool_unlock;
> 
> 	camel_folder_class->expunge = spool_expunge;
> 
> }
> 
> And implement it:
> 
> + static void
> + spool_expunge(CamelFolder *folder, CamelException *ex)
> + {
> +     /* Call the method on super */
> +     parent_class->expunge (folder, ex);
> +     return;
> + }
> 
> 
> On Sun, 2007-01-14 at 21:00 +0000, Seb James wrote:
> > Hi List,
> > 
> > I'm looking at the local provider for camel, written by Michael Zucchi.
> > It seems to be related to Bug 213072, which is now rather old, and which
> > affects me.
> > 
> > I'm trying to understand the code to begin with.
> > 
> > I use a standard unix mail spool as my inbox, and I am wondering why it
> > is that I can't expunge deleted messages from the spool. The spool just
> > gets bigger and bigger, filling up with messages, flagged as deleted.
> > 
> > So, question one to get me started is: What function in e-d-s carries
> > out message expunging, as distinct from message deletion?
> > 
> > regards,
> > 
> > Seb James
> > 
> > 
> > _______________________________________________
> > Evolution-hackers mailing list
> > Evolution-hackers gnome org
> > http://mail.gnome.org/mailman/listinfo/evolution-hackers