Re: [Evolution-hackers] EPlugin, export mail folder, now does recursive!

[smurfd <smurfd smurfnet homelinux net>]

> Hrm, right.  Hmm.  Do you want it to save all the folders into one
> folder, or alternatively create all the trees for it, or do you really
> want to just pop up a new save requester each time?
> 
> Each has different solutions.
> 
> The last one for example you probably want to do serialisation a bit
> differently, that is, copy the folder-info you get from the first call
> (see below for more info on what first call is), and then iterate
> through it in the folder_got callback rather than in the first
> callback. 
Hmm ofcourse the smoothest would be to get just one window asking for a
place and a name, then just save the rest automaticly with say adding a
.<name>.mbox to each..
example: 
you get a question where to save Inbox and you choose : ./Inbox and then
the subfolders Inbox/OLD, Inbox/Older, Inbox/Oldest gets the name
./Inbox.OLD.mbox ./Inbox.Older.mbox ./Inbox.Oldest.mbox .. But that
would Also mean to borrow some code from various static functions. 

hmm if you save everything to a mbox file, you cant retrive your
subfolders back, if you import it back, right? if so, i dont think thats
something i really want. 

And no, i dont really want to have a window pop up for each folder.
*shrug* would be pretty exaustive to export 200 subfolders. ;)


> url->fragment is only set for local stores, imap uses url->path.  Yeah
> its a hack.  In most code we just do url->fragment?url->fragment:
> url->path, although strictly you need to check the provider flags
> (store->provider->url_flags or something).

Cool, ill put that in then.. Ill grep the source for it will probably
give me an example on how.


> You forgot to free the folderinfo.  And the CamelURL, and you need to
> camel_exception_clear the exception when you're done.  C doesn't do
> garbage collection (at least evolution doesn't) so you have to manage
> that yourself. 
*Cough* my bad!


> Ok some of the seqeuences above are a bit wrong:
> - you really want to use "mail_get_store" first, to get the store, you
> can use the same uri, since it ignores the folder path part
> automagically (actually the store will always be loaded, so you can
> probably do that without mail_get_store, but for consistency you
> should stick to that, some camel ops in the mian thread can cause
> deadlocks).
Well if i would use folder->parent_store i wouldnt need to do that,
right? Or, were you talking about the "do_export_mail_folder() function?


> - you need to use mail_get_folderinfo too, the 'done' callback will be
> invoked back in the main thread, you want this potentially
> long-running stuff to run in the background.
> - then you can iterate the results of mail_get_folderinfo in its done
> callback, and call the mail_get_folder as appropriate.
> 
> All of the 'mail_*' functions run in another thread then return the
> processing to the main thread, and then call your callbacks.  So if
> they need to do more camel ops they should do more threading stuff. 
> Since this might need to alternate to gui and camel ops its probably
> easist to stick to above, if you could just do it all in a non-gui
> thread you'd just setup a new 'mail op' thing, and just use direct
> camel codes in the other thread.
> 
> 
> Maybe some of what i'm saying doesn't make immediate sense, but there
> are reasons for doing it this way.
> 

Yeah ill re-read it a couple of times, and digg some code ill understand
:)

Thanks very much for some good pointers and the help!

/Nicklas