GNOME.org
 

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

But is an SQL solution not much more flexible? For example you would have
very powerful tools at hand to access the mailbox from outside Evolution.
I'm sure that when some users ask for such a solution they will have their
reasons. In my humble opinion it would be very unwise to close the door to
this option, although I think for most users the mbox solution will work
better, because it is simpler to set up.


----- Original Message -----
From: "Jeffrey Stedfast" <fejj ximian com>
To: <daniel 2totziens com>
Cc: <evolution helixcode com>
Sent: Friday, January 19, 2001 1:59 PM
Subject: Re: [Evolution] Storage .pst(s) & standard mboxes



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

Jeff

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


_______________________________________________
evolution maillist  -  evolution helixcode com
http://lists.helixcode.com/mailman/listinfo/evolution



_______________________________________________
evolution maillist  -  evolution helixcode com
http://lists.helixcode.com/mailman/listinfo/evolution
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]