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

[Tim Hanson <tjhanson home com>]

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

Where I work we're limited to 100mb, and believe me it fills up fast. 
In any organization it doesn't take long before email is the preferred
method of transferring anything and everything: .pdf files, forms and
documents with embedded graphics, spreadsheets, you name it.  I always
download mine to a local folder but a lot of people don't, so it sits
there on the server.  Lots of people are surprised when they come to
work one morning to find their mailbox won't take new email.

> 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
>
> _______________________________________________
> evolution maillist  -  evolution helixcode com
> http://lists.helixcode.com/mailman/listinfo/evolution

-- 
If a camel is a horse designed by a committee, then a consensus
forecast is a camel's behind.
                -- Edgar R. Fiedler