> 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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
