On 12 Jun 2001 22:09:40 +0500, Dan Winship wrote:
> > You can't just yet anyway; you can create a spool file 'folder', but it
> > doesn't show up anywhere, and can't be opened from the gui yet; have to
> > work something out on how to make this happen (which hopefully isn't the
> > same awful hack used for local stores, sigh).
> 
> The awful hack for local stores is because the shell does half the
> bookkeeping (and Ettore and I are talking about how to fix it.)

I know, its still an awful hack!

> For spools and maildirs, you just want to implement
> CamelStore::get_folder_info and use the same code paths to create the
> storage and fill in the folders as IMAP does.

Ok, this only works if the store knows about its folders, which means
the shell will need to treat all folders similar to the way it does
imap.

> For a spool file, the folder tree would just be the one folder, I guess.

Hrm, I see.  I guess that would work, then the same should be done for
mbox folders too?

> I think the standard for maildirs is to do:
> 
> path/{new,tmp,cur}
> path/.foo/{new,tmp,cur}
> path/.bar/{new,tmp,cur}
> path/.bar/.baz/{new,tmp/cur}
> 
> (note the dots) for
> 
> path
>  |-foo
>  +-bar
>     +-baz
> 
> where "path" is a folder too. This is how Courier imapd sets things up
> anyway. (Assuming "path" was ~/Maildir/, it would call the folders
> "INBOX", "INBOX.foo", "INBOX.bar", and "INBOX.bar.baz".)

Ok, if this is done, then the same (as in, camel controls the tree, not
the shell) will have to be done for mh and mbox folders too.

Also, with the mail 'sources' section, we need some way to differentiate
between mail files that get imported (run through filters, deleted,
etc), and those that dont (like imap, etc).  Although just having
different types does that more or less (well, you may want a spool
folder that stays there, or one that gets imported, so the provider
flags might not be useful enough here?)

 Z



_______________________________________________
evolution-hackers maillist  -  [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/evolution-hackers

Reply via email to