Re: [Evolution] Filing system

[NotZed <notzed helixcode com>]

> How is evolution going to support IMAP if all messages are in one file?  Should

Uh, all messages aren't in one file.  A single mbox folder is a single file,
but you can have multiple mbox folders, and imap folders are well, imap
folders.

> it be all messages in one file [mbox] per folder/mailbox?  If it's set up as a
> POP account then no problem. Currently I have about 15 folders and all messages
> are filtered into the appropriate folder with a 100MB IMAP account.  Can't
> vfolders search across multiple mbox files?

Thats the intention, yes.  Remember, vfolders dont even exist yet.

> from http://www.imap.org/papers/imap.vs.pop.brief.html
> IMAP can access and manage multiple mailboxes. This includes the ability to name
> and access different incoming and archive message folders, but also the ability
> to list, create, delete, and rename them. These mailboxes can be on the same
> server or on different servers. An IMAP client may allow you to see them at the
> same time, and move messages from one to the other.

Well, camel is basically an imap interface to any mail repository.
Myabe that answers your questions.

> IMAP can support concurrent updates and access to shared mailboxes. This
> capability is useful when multiple individuals are processing messages coming
> into a common inbox. Changes in mailbox state can be presented to all
> concurrently active clients via IMAP.
>
> IMAP4 is defined in RFC-1730.

Try rfc 2060, which is newer.

> On Wed, 10 May 2000 11:30:03 -0400
>  "Bruce C. Dillahunty" <bdillahu peachbush com> wrote:
> #On Wed, May 10, 2000 at 12:17:55AM -0400, NotZed wrote:
> #> > 
> #> > 
> #> > My concern with Evolution is the direction of storing mail in mbox (or
> #IMAP or 
> #> > ...) files, instead of a database. The virtual folders are the way to go,
> #as 
> #> > far as I'm concerned, but is this the right backend???
>
> #> an indexed flat file isn't
> #> really any performance problem at all (and you can even repair it
> #> with vi!).  Even less so when you have virtual folders, since it
> #> isn't actually moving messages around, just performing queries.
> #> 
> #> What we have IS a database, it just doesn't look like one.
> #> (and no silly arguments about what constitutes a database and
> #> what doesn't).
> #> 
> #
> #Hmmm... hadn't really thought about it that way, but you have a good point. I
> #don't think about the gains you can get from indexing (I know nothing about it
> #except from a user point of view).
> #
> #Having stuff in a text file that I can access via vi or whatever is a definite
> #plus. How well do things scale in this arena? If I put all of my mail in one
> #text file, I would have 100+ Mb (probably more than that... haven't tried it 
> #:-) How efficient is searching across files? I would assume its probably not
> #much worse than a single file. 
> #
> #Now I get the concern of where does the particular message live? 
> #Or should I just not care? When it comes in, it needs
> #to be filed somewhere, but it may be accessed through many virtual folders, or
> #whatever. What's the best scheme for this for efficiency, etc.? Maybe I'm too
> #far ahead in the game here (let the poor developers finish :-). I just think
> #about how I would use the tool... in essence, I don't want to have to think
> #about filing my mail... I just want to query the "database" and get all mail
> #from joe, or all unread mail, or whatever (using vfolders).
> #
> #Another "requirement" that I don't see how to handle is mail that goes with a
> #particular "project" or whatever... some things you just can't query. My best
> #example is my "humor" file... it may be about anything (whatever I thought was
> #funny), it may be from anyone, and it may still apply to a main subject (i.e.
> #it went with my work file and should still be associated there also). My 
> #thought is to add an "attribute" or flag to a message marking it "humor".
> #Maybe
> #an extra header? Then my humor vfolder could find all messages with that flag.
> #What would be a good way of doing this?
> #
> #Is this making any sense... I guess I'm just not up on things enough to be
> #comfortable with actual implementation. I haven't been able to spend the time
> #to upgrade the world on my machine so that I can compile evolution (now
> #holding out for the snapshots), so I haven't just tried some of this.
> #
> #Please ignore if you like.
> #
> #Bruce
> #
> #
> #> 
> #> 
> #
> #-- 
> #Bruce C. Dillahunty
> #Peachbush Enterprises
> #bdillahu peachbush com
> #