master_at_internexus.net said:
| I really like the maildir suggestion. 
| The one problem that I see is that if you have mail.example.com
| pointing to both client coda machines for pop/imap work, a message
| might be delivered to one of them before the other, in other words
| theres a race condition.

| The user contacts 'mail.example.com' and it resolves to one of those
| machine IP's to get mail, only to resolve again at the next interval
| to find that its hit the other machine where it isnt all there yet.

But if the clients are all strongly connected to the coda-servers, any
update will trigger a callback message to be sent to the other (coda-)
clients, and those clients will then refetch the new directory contents
from the server(s) on the next access. So there shouldn't be a race
condition there (as long as the clients do not become disconnected).

It would even be possible to have the delivery on one set of machines, 
and the pop servers on a completely different set of hosts.

But, actually, before we can reliably support such a 60000 pop-clients
mail server setup, there are still some very important issues that need
to be worked on:

 - scalability,
   We need much larger servers and bigger client caches, and this is 
   not easily `tweakable', there are some serious changes necessary.

 - reliability,
   Getting more of the bugs and races fixed, everytime we reach more 
   stability, people start to use the system in new ways, and new
   problems surface.

 - small/medium scale testing,
   Nobody has ever done maildelivery in a Coda filesystem, not even for
   a single user. Yes, here a couple of us crazy developers do store our
   email in Coda, but the delivery is still done to the local disk and
   only the `received' mailboxes are stored in /coda.

Jan