On Sun, 2 Feb 1997 17:22:05 -0500 Brad Knowles <brad@his.com> said:
> If you now want to see if they're over a certain quantity of
>mail, measured in bytes, instead of just slicing through the mailbox and
>counting how long it takes you to get to the end, you now have to store
>message size along with the pointer to the message, and run an
>accumulated total as you're walking down that tree. It doesn't sound
>like much, but do it tens of millions of times a day, and you'll quickly
>accumulate a lot more CPU time than you thought possible.
This is an implementation problem that can be solved in all sorts of
ways, such as maintaining a "total size of mailbox" field in the mailbox
header or whatever makes sense given your existing implementation. As one
of my former bosses used to say when I explained that his latest bright
idea wasn't going to work, "Stop! I don't want to hear any of that. This
stuff is your job, not mine. My job is to decide if we can afford it, so
just tell me who would have to work on it for how long and what hardware
we would need to buy, and I'll give you an answer".
> We'd probably have to add several dozen more terabytes of disk
>storage (because the average mailbox size would grow *dramatically*),
That's a valid argument, but you can charge extra for the service, or you
can contain the growth by adding a higher per-message cap. To tell you
the truth, I think most people would be happy with 1000-1500 total. It's
just that if you divide 500 by the number of days in a long weekend, it's
less than what most active lists produce a day. People then lose personal
mail and get upset.
Eric
Follow-Ups:
|
|
