[Evolution] Storage .pst(s) & standard mboxes

["Daniel Ashley" <daniel 2totziens com>]

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
looked into.

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
earlier e-mail:

        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.

Thank you.

        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
        to corporations!

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?
iduno

Daniel Ashley
just some I.T. janitor