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

[Not Zed <notzed ximian com>]

On Sat, 2004-11-20 at 21:24 +0100, smurfd wrote:
> > 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, I think there's a save-messages thing which runs non-interactively too (unless it fails).  But even if you need to cut and paste some code it shouldn't be much.

Also, as for the file structure, sure I guess anything could do.  You could just use the same format evolution uses (which is similar to what mozilla uses) where the actual mbox file names would be Inbox, Inbox.sbd/Older  Inbox.sbd/Oldest for your example.  In that case you might just ask for a directory in which to start saving the toplevel one, and just copy the same folder names.

> 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. 
Well it depends on what you're implementing.  Export/import is somewhat different from just saving folders.

If you're really doing an import/export i.e. for backup or archival, you probably want to do something to save it as a single file anyway, like a tar or a zip file or something (preferrably something you can also access via other means).  Then if you got really fancy it could also be a system which let you access it directly 'read only' without having to un-archive it by writing a custom camel backend.

> > 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?
Well depends on how you do it.  You're getting the first folder and then getting the folderinfo, ideally you should just be getting the folderinfo then get each folder by iterating over that list.

But either way could work, the second way separates the functionality a bit more clearly, thats all, and you only have 1 place you get all folders and do the folder processing, etc.

--

Michael Zucchi <notzed ximian com> "Free Software, putting the Free back in Free Market." Novell's Evolution and Free Software Developer