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

[smurfd <smurfd smurfnet homelinux net>]

> 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.
Okey Ill look into that. It depends, i did look on howmuch i needed to
copy for the em_utils_save_messages() function to work, it got like 4-5
functions.. but yeah, it aint to 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.
That do sound pretty good. Ill try to find that non-interactive
function.
 
> 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.
That custom camel backend thingie, do sound pretty sweet. But i think
its abit Too fancy right now. Ill start with getting it to work. Then, i
might look further into that. Because it would be something like the
import backend camel has today, right?

Well in the beginning, i really wanted to have it put into a compressed
matter, for archiving/backup means. But thought it would be to much
work, so i settled at first to just copy each folder.

How would one go forward getting that compressed exportion working?! 

What did you mean by "(preferrably something you can also access via
other means)"? 


> 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.
Ahh i see, that would ofcourse mean less resource demanding. If i only
get_folder_info once. instead of for each subfolder. True.

/Nicklas