Re: [Evolution-hackers] camel local provider and Bug 213072
On Thu, 2007-02-22 at 22:52 +, Seb James wrote:
> Hi Philip,
>
> I've not done any work on this recently, but I've not forgotten it; just
> been busy with other things.
>
> On Tue, 2007-01-16 at 05:44 +0100, Philip Van Hoof wrote:
> [snip]
> > If you want to implement a specialised version for "spool" folders, fill
> > in the function pointer like this:
>
> (in camel-spool-folder.c)
>
> > 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;
> > + }
>
> Ok, I guess in this function, I'm going to have to get down and dirty
> with the spool file:
>
> Call spool_lock()
> Read it in, skipping expunged entries
> Write it out, sans expunged messages
> Call spool_unlock().
>
> Questions for anyone on the list:
> Is there a formalised way of getting the path to the spool file?
Got it:
CamelLocalFolder* localFolder;
int fd;
/* ..set up localFolder.. */
fd = g_open(localFolder->folder_path, O_LARGEFILE | O_WRONLY | O_BINARY, 0600);
> What are the camel functions for stepping through a mail file, looking
> at each message?
> Is there a "camel read message to data structure" kind of function?
I think the relevant functions are in camel_mime_parser.c
>
> Seb
>
> My original posting:
>
> > On Sun, 2007-01-14 at 21:00 +, 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
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel local provider and Bug 213072
Hi Philip,
I've not done any work on this recently, but I've not forgotten it; just
been busy with other things.
On Tue, 2007-01-16 at 05:44 +0100, Philip Van Hoof wrote:
[snip]
> If you want to implement a specialised version for "spool" folders, fill
> in the function pointer like this:
(in camel-spool-folder.c)
> 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;
> + }
Ok, I guess in this function, I'm going to have to get down and dirty
with the spool file:
Call spool_lock()
Read it in, skipping expunged entries
Write it out, sans expunged messages
Call spool_unlock().
Questions for anyone on the list:
Is there a formalised way of getting the path to the spool file?
What are the camel functions for stepping through a mail file, looking
at each message?
Is there a "camel read message to data structure" kind of function?
Seb
My original posting:
> On Sun, 2007-01-14 at 21:00 +, 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
Re: [Evolution-hackers] camel local provider and Bug 213072
On Wed, 2007-01-17 at 19:19 +0100, Philip Van Hoof wrote: > On Tue, 2007-01-16 at 10:05 +, Seb James wrote: > > > So, do you think it makes sense for e-d-s to expunge messages from > the > > unix mail spool? > > > It makes sense that you want to try it. Whether that also means that > the > Evolution Mailer maintainers will include your code is a different > question. > Any contributions that helps a project and its users will definitely make its way to the mainstream. It is just a matter of time and availability of the respective maintainer(s) that decides the duration to merge it upstream. Thanks, V. Varadhan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel local provider and Bug 213072
On Tue, 2007-01-16 at 10:05 +, Seb James wrote: > So, do you think it makes sense for e-d-s to expunge messages from the > unix mail spool? It makes sense that you want to try it. Whether that also means that the Evolution Mailer maintainers will include your code is a different question. You can, however, distribute your own Camel provider and register it in the system in such a way that yours would be used if for example the url_string starts with sebjames_spool://, that way you could flock users to your implementation of the spool (in case the Evolution Mailer maintainers aren't interested) (if you register it correctly, it will even appear in the "New account" wizard of Evolution). I am, being the tinymail author, however interested in the code that you would produce. On a mobile devices (which is the target audience of the tinymail framework) it makes sense to get rid of not-needed information as soon as possible. Tinymail uses a forked version of Camel. The local providers haven't had many changes so your code would probably flow in automatically. > Thanks again for the explanation you gave, it's very helpful! No problem -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel local provider and Bug 213072
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
Re: [Evolution-hackers] camel local provider and Bug 213072
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?) :-)
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);
}
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 +, 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
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
