Re: [Evolution] Storage .pst(s) & standard mboxes
- From: Jeffrey Stedfast <fejj ximian com>
- To: daniel 2totziens com
- Cc: evolution helixcode com
- Subject: Re: [Evolution] Storage .pst(s) & standard mboxes
- Date: 19 Jan 2001 00:59:48 -0500
I have an 80 meg Inbox. Just out of curiosity, I just cat'd 2 copies of
it into my Drafts folder and loaded Evo on up - handles it great.
It loads very fast still, and I don't notice any difference in speed to
grab an arbitrary message in my (now) 160 meg folder as I do in one of
my other folders that has a mere 5 messages in it.
No scalability problems here...why? because we index the mail. When you
click on a message we just jump x bytes into the mbox and read y bytes
and that's our message (x and y being held by the summary). I don't see
huge sums of mail being an issue here. Or at least not any more of a
problem with mbox than an SQL database.
All this worry over nothing...
On 18 Jan 2001 22:31:10 -0800, Daniel Ashley wrote:
The storage medium of Outlook as many of you know is the outlook.pst
file. It is called an outlook.ost file if it is set to 'slave' to
synchronize with the Exchange database. The theoretical storage limit
of a .pst file is 2GB. The practical limit is 300-600MB. The practical
limit for an .ost file is the same. After 700MB corruption can be a
weekly issue. I have had to deal with customers with over 3GB of mail
that was stored on the Exchange server. The average/mean customer that
I have dealt with stores 80-90MB of mail. In a company of 100-150
people there will -always- be 6-8 with 500+MB of mail. I have done my
fair share of consulting in San Francisco & NY to be familiar with these
issues. Put that into perspective to a 10k+ company. People like
Ellison of Oracle has well over 10GB of e-mail that was flushed
regularly. This information came from Ray MacDonald the former head of
internal I.T. support for Oracle.
"...Evolution should be able to handle 40+ megs of mail without a
problem..." No offense intended... I hope that this limitation is
The reason that Mr. Hakala brings up the topic if storage is that I
wrote to him regarding conversion of .pst files into a format that is
compatible with Evolution. I regret not posting it to the whole group
earlier. Mr. Hakala - hope you don't mind me quoting you from an
The only way to get at the info in a PST is through MAPI
(not to be confused with the 12-function Simple MAPI --
I'm talking about the fattest, most unwieldy API ever
made;). So building a tool to migrate from a PST to
Evolution's format is possible. This is also how you'd
migrate someone's data from an Exchange store into Evolution
since many corporate users are live against the Exchange
server and use OSTs for syncing, which are really just PSTs
at heart). Before my Microsoft days, I did a lot of MAPI
work (as a consultant to MS) so I'd love to help out if
people were interested in starting such a project.
As an aside, I don't know how Evolution stores its data, but
whoever is working on that should really look into using SQL
if not already.
I agree with you whole heartedly about using SQL as the storage medium.
As Mr. Winship reports "Contact, Calendar and To-do items are stored in
Berkeley db files." this presents a challenge to whoever is doing the
.pst conversion. They have to export to mbox And Berkeley db file(s).
This presents another two challenges. Debugging a corrupted mbox and a
Berkeley db file. For the beta user it is easy to start over if the
mbox gets corrupted. I.T. support people can't tell the CEO with .7GB
of mail to start over or work off of a one week old backup. And for
those of you saying that he should backup every day... it might be
difficult when he/she has a laptop & was overseas with business. A
solid debug tool is a must. I'll go out on a limb as a DB novice & say
that an SQL consistency checker might already be in existence.
This was a HUGE deal in Outlook.... we were
going to move to a complete SQL store (MS is trying to do this
across the board in all products, actually) but because Outlook's
code was such a mess and totally MAPI-centric, this was not easy
and was not done and probably never will be done. In fact, the
forthcoming Outlook 10 almost used a completely new store, one
that was based on a smaller version of the native Exchange store
(which, for stupid reasons, is not SQL-based either) that would
provide much better performance than the PST/OST and would be a
more robust db. But that was just recently cut as well after a
whopping 2 years of development, so Outlook 10 will have the same
poor store it's always had.
I couldn't agree more.
So the lack of a good store is a HUGE weakpoint for Outlook and
customers know it and MS can't do anything about it. If Evolution
had a robust, fast and easily-synchronizable store with a usable
API for 3rd party access, Evolution would look *very* attractive
If the "local store" for Evolution was SQL & future open source
groupware was based on SQL then wouldn't the API be easier to develop?
just some I.T. janitor
evolution maillist - evolution helixcode com
] [Thread Prev