Re: [Evolution-hackers] EPlugin, export mail folder, Update!

[smurfd <smurfd smurfnet homelinux net>]

>Using the mail-mt stuff is good since it does some of the setup work
>for you, and lets you setup 4 callbacks, one to say what you're doing,
>one to do the work in the other thread, one to do any work back in the
>gui thread, and one to clean up.  You also have a little control over
>scheduling - i.e. should it run in a new thread or just use one of the
>thread queues, so you don't get too much thrashing.

Ah okey, well i have been into using that sollution a couple of times,
but well i still havent really got it to work as i wanted it.

Today i realised Why i havent got it to work as i wanted it.
 
well i have 3 functions in that struct that gets executed, and thought
that a 4th could be used to run the compression part there.
so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here
was to get __exp to deliver the mails to the location where i wanted it,
say /home/smurfd/backup/ and then to run the compression on That
folder. 

Why you ask, why not just run the compression on the right-clicked
folder? Well ive been heavily debating this (with myself) and after many
debates, i came up with that running it on the exported directory would
be better, since than i wouldnt have to care about if the user
right-clicks a non-local folder, say IMAP or whatever for the
compression part.

sounds sane?

That way, i need to have the "exportion" part to be finished Before the
compression part takes place.
Easy, just have the compression part take place in the __cpio function,
right?
NO, that wont work, and after serious thinking, serious headsmashing, i
realised Why that is...

Thats because in the __exp i have 'mail_get_folder()' wich itself spawns
a new thread, and that way, the __exp thinks its work is done, before it
"really" is...

So im gonna have to borrow some more code i guess... and make small
modifications on it to fit my needs.

Better to re-use, than to re-invent i guess. :)

Best regards
/Nicklas