Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Feb 2003 19:42:52 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Brad Knowles <brad.knowles@skynet.be>
Cc:        Rahul Siddharthan <rsidd@online.fr>, freebsd-chat@freebsd.org
Subject:   Re: Email push and pull (was Re: matthew dillon)
Message-ID:  <3E49C2BC.F164F19A@mindspring.com>
References:  <20030211032932.GA1253@papagena.rockefeller.edu> <a05200f2bba6e8fc03a0f@[10.0.1.2]> <3E498175.295FC389@mindspring.com> <a05200f37ba6f50bfc705@[10.0.1.2]>

next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles wrote:

[ ... single instance message stores ... ]

>         In practice, as we scale up the system, this really isn't that useful.
> 
>         See
> <http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld086.htm>;
> and
> <http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld087.htm>.


Actually, I disagree with this presentation.  There is an assumption
of "sufficient storage" there in the first place, when in practice,
sufficient storage is commonly a prime economic issue.  If people
were satisfied with the job "the big providers" were doing, there
would be no little providers.

As to the metadata updates: I'm not positive this is the case,
though it is certainly the case in "sendmail" and certain other
MTAs.  It's really implementation dependent, I think, and the
slide assumes a particular implementation.


>         Moreover, do you know how painful it is to lose a cc:Mail, Lotus
> Notes, Microsoft Mail, or Microsoft Exchange database?  You can
> instantly toast all mail for all users on that post office.  Of
> course, you can only support about ~150 users per post office, but
> then you have to manage a great many more post offices and your TCO
> goes way, way up.

The scaling issue at 150 is an implementation detail specific to
the implementations you are referencing.  My advice is "get some
real software".  8-).  You can scale something like this from
Open Source components and about 3 months of concentrated coding
to at least 50,000 per indivisible component cluster, and then
throw hardware at it.

The normal implementation to avoid single point of failure is
replication of the data.  At that point, the replication
protocol itself becomes (essentially) a transport.  The worst
case failure mechanism, in that case, is a previously deleted
message reappears.


>         How else do you think that Oracle can pitch their "Make Exchange
> Unbreakable" solution, where as damn bloody expensive as the hardware
> is that they base their solution on, the freakin' Oracle software
> licenses are actually more expensive, and yet still make the sale?
> They do it on TCO, and they do actually get the sales....

I think they do it on the basis of their name, and on the basis
of the idea that "you can put any SQL server behind MS Exchange,
so use ours, it's better than Microsoft's".

I agree that, in one narrow view, this can translate to TCO, but
it's not the major view that most people who are making the Buy
Decision are coming from.  Even coming from that point of view,
you see mistakes made (e.g. Oracle vs. California).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E49C2BC.F164F19A>