But then the commercial model for those who don't believe in "free-as-in-beer" software collapses... The whole idea is to pay for what you use. Since most Open Source makes you pay for the knowledge, instead of for the "Right to use" those people SHOULD stay more expensive than the "per license" seat specialists... In fact... it only makes sense, in a market economy, that if a customer has X money for a project, and you reduce costs, it ends up partly in the pockets of the people who help you save that money... Otherwise they'll go save money... for someone else...
-- Being a cheapskate does not pay Not paying for more than you need/use does... PHBs seldom seem to understand that
It's interesting that very few comments/analysis/quotes highlight the fact that the language molds your thinking, making one type of error more or less likely.
If you find this strange, I would submit that speaking human languages influences the way bilingual people think, so software programming would draw upon the same phenomenon.
It's the whole "I got a hammer and a nail and a saw and a drill thing..." You can't talk about bas-relief... 'cuz you don't have a chisel. Or if you do, it's in your other toolbox...
Strongly-typed languages may be more effective in preventing type errors by making the programmer think about the type of variables... than by the compiler catching any... And there is also the question of code style to consider... a weakly & dynamically typed language may have just as few bugs if it's coded with strong code guidelines... Of course, then we may just be getting back to the "good programmer makes good code" syndrome
I doubt I'll be alone in the opinion that the above discussion kinda emphasised the need for a particular method of access being tailorized to your needs, and not everyone's needs being the same...
Do you know WHY?
Because the format is rather extensible, and adding/removing/rewriting headers, when you don't know how many of each are supposed to be, isn't such a good idea(think about the "Received:" headers, for which there must be several formats, perhaps as much as a dozen) the X-headers are another kind of hard-to-mess with "content" That leads the MDA and MUA to use the same format, to minimize the number of operations on each email, etc.. (They don't NEED to have the same(sylpheed converted an mbox I had into mx(or mbx) which was nice, if unexpected, yet not wholly what I wanted)
Now what does that have to do with anything? Well it's no coincidence that most MUA(mail user agent aka mail client) REUSE the work of the MDA as much as possible... It's easier to have high performance when you don't have to do anything... Now most people only use ONE mua to read all their mails... But most systems administrators manage servers where not everyone uses the same MUA (yes if you're a sysadmin I'm preaching to the choir...) Locking and compatibility become important... otherwise you have to remember joe wants his mail in mbx format and dave wants it in maildir, so you can deliver to them... hence the lowest common denominator has its advantages... and why do work when the client will make you redo it(think people with enough procmail rules to consume 1 minute of cpu per incoming message)
Now think... all of this has to do with the link between mua and mda formats... What's the future for storage of emails? well if you are writing a client and have access to something like camel, which lets you choose the format as you see fit... You sure aren't hurting your chances, are you? You KNOW everyone likes their email du jour different...
Now what does that mean for servers? Well I can see the mailfront project(where the "front end" or "customer facing") is seperate from the "back end" or processing unit, allowing one to basically mix and match, or at least to integrate seperate approaches more easily as an approach with lots of future...
What does that change? Well for having tried alternate file systems and alternate mail"drop" formats a lot in recent months, I can tell a smart sysadmin will want to choose the filesystem and mail"drop" format together... as an optimisation measure... Lots of people don't seem to like maildir... on e2fs... Where it's not at its best... But put it on reiserfs... and it flies.. why? Simple... The filesystem is a data retrieval method... and your mail"drop" is a database of sorts... Would you just pick the database that comes with your operating system, because it comes with the operating system... with no thought to size or performance or contention or locking? I know I wouldn't... Now databases et al... are all good ideas... for the right needs... Does everyone need the same mail server? No... I use courier, on reiserfs... it does what I need...
For a larger setup... copying the headers for indexing purposes is a good idea... IF you search your email a lot... Which is why it makes sense for evolution to do it... most people don't search email ON THE SERVER... they search a local copy... (or hopefully cache some of the metadata instead of brute-force download all messages of a mailstore...) Does it make sense on a pop-toaster? Probably not, most people don't "Keep" mail long enough for it to make sense... But some do... And it probably was how the original idea of exchange/domino/etc... developed... a database you subscribe(as in publish/subscribe, not as in cash) to... that gives you access to your email/meetings/etc...
From the namesys project's web page, it appears some people are working to integrate reiserfs into maildir to a greater degree, allowing more efficient searches, headers stored as attributes, etc... All lovely ideas... for the right client...
The same with embedded databases(bdb, gdbm, cdb, etc...) or generic relational or object databases... For some people they make a lot of sense... For the pop toaster kind of setup, it seldom makes sense: the "end users" don't appreciate the kind of work involved into making searches fast(most of them don't search too often "live" over hundreds of folders in a webmail type of situation for example).
Of course in a smaller office, with say a pair of email power users with a gig or two of emails for "data mining" purposes such databases might mean the difference between life and death...
On that note mbox is probably fine for up to a hundred messages... if a bit slow... maildir might get scary after 100000 messages(especially on e2fs, inode vs directory table considerations...)
Does it make sense to spend lots of work on performance vs compliance to standards vs interoperability? Depends on patterns of access, installed base, usage metrics and other such considerations... But email is a tool... Like all tools, what's important is: What are you going to use it for today?
Slashdot Mirror
But then the commercial model for those who don't believe in "free-as-in-beer" software collapses...
The whole idea is to pay for what you use. Since most Open Source makes you pay for the knowledge, instead of for the "Right to use" those people SHOULD stay more expensive than the "per license" seat specialists...
In fact... it only makes sense, in a market economy, that if a customer has X money for a project, and you reduce costs, it ends up partly in the pockets of the people who help you save that money... Otherwise they'll go save money... for someone else...
--
Being a cheapskate does not pay
Not paying for more than you need/use does...
PHBs seldom seem to understand that
It's interesting that very few comments/analysis/quotes highlight the fact that the language molds your thinking, making one type of error more or less likely.
If you find this strange, I would submit that speaking human languages influences the way bilingual people think, so software programming would draw upon the same phenomenon.
It's the whole "I got a hammer and a nail and a saw and a drill thing..." You can't talk about bas-relief... 'cuz you don't have a chisel. Or if you do, it's in your other toolbox...
Strongly-typed languages may be more effective in preventing type errors by making the programmer think about the type of variables... than by the compiler catching any... And there is also the question of code style to consider... a weakly & dynamically typed language may have just as few bugs if it's coded with strong code guidelines... Of course, then we may just be getting back to the "good programmer makes good code" syndrome
I doubt I'll be alone in the opinion that the above discussion kinda emphasised the need for a particular method of access being tailorized to your needs, and not everyone's needs being the same...
Do you know WHY?
Because the format is rather extensible, and adding/removing/rewriting headers, when you don't know how many of each are supposed to be, isn't such a good idea(think about the "Received:" headers, for which there must be several formats, perhaps as much as a dozen) the X-headers are another kind of hard-to-mess with "content" That leads the MDA and MUA to use the same format, to minimize the number of operations on each email, etc.. (They don't NEED to have the same(sylpheed converted an mbox I had into mx(or mbx) which was nice, if unexpected, yet not wholly what I wanted)
Now what does that have to do with anything? Well it's no coincidence that most MUA(mail user agent aka mail client) REUSE the work of the MDA as much as possible... It's easier to have high performance when you don't have to do anything... Now most people only use ONE mua to read all their mails... But most systems administrators manage servers where not everyone uses the same MUA (yes if you're a sysadmin I'm preaching to the choir...) Locking and compatibility become important... otherwise you have to remember joe wants his mail in mbx format and dave wants it in maildir, so you can deliver to them... hence the lowest common denominator has its advantages... and why do work when the client will make you redo it(think people with enough procmail rules to consume 1 minute of cpu per incoming message)
Now think... all of this has to do with the link between mua and mda formats... What's the future for storage of emails? well if you are writing a client and have access to something like camel, which lets you choose the format as you see fit... You sure aren't hurting your chances, are you? You KNOW everyone likes their email du jour different...
Now what does that mean for servers? Well I can see the mailfront project(where the "front end" or "customer facing") is seperate from the "back end" or processing unit, allowing one to basically mix and match, or at least to integrate seperate approaches more easily as an approach with lots of future...
What does that change? Well for having tried alternate file systems and alternate mail"drop" formats a lot in recent months, I can tell a smart sysadmin will want to choose the filesystem and mail"drop" format together... as an optimisation measure... Lots of people don't seem to like maildir... on e2fs... Where it's not at its best... But put it on reiserfs... and it flies.. why? Simple... The filesystem is a data retrieval method... and your mail"drop" is a database of sorts... Would you just pick the database that comes with your operating system, because it comes with the operating system... with no thought to size or performance or contention or locking? I know I wouldn't... Now databases et al... are all good ideas... for the right needs... Does everyone need the same mail server? No... I use courier, on reiserfs... it does what I need...
For a larger setup... copying the headers for indexing purposes is a good idea... IF you search your email a lot... Which is why it makes sense for evolution to do it... most people don't search email ON THE SERVER... they search a local copy... (or hopefully cache some of the metadata instead of brute-force download all messages of a mailstore...) Does it make sense on a pop-toaster? Probably not, most people don't "Keep" mail long enough for it to make sense... But some do... And it probably was how the original idea of exchange/domino/etc... developed... a database you subscribe(as in publish/subscribe, not as in cash) to... that gives you access to your email/meetings/etc...
From the namesys project's web page, it appears some people are working to integrate reiserfs into maildir to a greater degree, allowing more efficient searches, headers stored as attributes, etc... All lovely ideas... for the right client...
The same with embedded databases(bdb, gdbm, cdb, etc...) or generic relational or object databases... For some people they make a lot of sense... For the pop toaster kind of setup, it seldom makes sense: the "end users" don't appreciate the kind of work involved into making searches fast(most of them don't search too often "live" over hundreds of folders in a webmail type of situation for example).
Of course in a smaller office, with say a pair of email power users with a gig or two of emails for "data mining" purposes such databases might mean the difference between life and death...
On that note mbox is probably fine for up to a hundred messages... if a bit slow... maildir might get scary after 100000 messages(especially on e2fs, inode vs directory table considerations...)
Does it make sense to spend lots of work on performance vs compliance to standards vs interoperability? Depends on patterns of access, installed base, usage metrics and other such considerations... But email is a tool... Like all tools, what's important is: What are you going to use it for today?