Greetings!

I'm presently evaluating Coda for production use in an ISP-like
environment.  I know the, erm, slightly elderly Coda website does not
recommend this.  I also get the impression from the list I wouldn't be
the first to disregard that warning.  I've spent some time getting up
to speed with Coda and deploying it on my home network, but it's clear
I'm not going to be able to develop a comprehensive understanding very
quickly.  Time is precious though, and I'm still uncertain whether I
should commit to this solution or cut my losses and try something
else.  I'm prepared for a few headaches, what I'm worried about are
the potential show-stoppers that I might not be seeing.  I'd sure
appreciate any input the list can offer.

We would like to replicate the mailboxes and web folders for up to
roughly 33,000 users.  (The initial requirements would be 1/10 - 1/100
of that.)  There will be two hosts acting as mail servers, and two
acting as web servers.  The "secondary host" of each pair will serve
as coda servers.

It's my understanding that the maildir mailbox format is generally
recommended for delivering to network filesystems, though there are
gotchas on Coda because of the lack of inter-directory hard links.
So, there's a sort of de facto standard for maildir on Coda that just
assumes coda will make rename instead of link-and-unlink safe.

Is maildir still the state of the art?  I think there are other
one-file-per-message formats.  Are they more likely to generate
collisions and conflicts on Coda?

What maildir delivery and mailbox software is known to follow the de
facto standard?  If I have to test a new package, what actions use
cross folder links, according to the spec?  Does the server ever do
this, even, or is it strictly a mailreader issue?

Also, has anyone hacked gnu's nnmaildir module to work with coda yet?
(That's just for me.  I moved all my email onto a coda volume.  It
took many hours, and now it's darn well staying there.  ;-) )

We will have two servers accepting mail from the Internet.  We would
like to have complete redundancy, so rather than having the secondary
server just hang onto mail until the primary server comes back up,
we'd like it to deliver any mail it gets right to the shared maildirs.
That way users can still get to email that comes in during an outage
of the primary server.  Is this a completely stupid idea?  Will it
"just work" or am I going to have to do some hacking?

Lastly (for now), we pretty much have to avoid exposing coda conflicts
to the end user.  I'm still shaky on manual conflict resolution, so
it's really unclear to me whether or not it will be possible to take
care of conflicts via policies, or some other mechanism.  The manual
suggests conflict resolution can be automated for some cases, but it
seems rather vague about it.

It seems to me that, so long as I can make sure there cannot be
multiple mailreaders active on the same volume but on different hosts,
there is no possibility of a conflict, no matter what the (assumedly
sane) mail delivery agents may do.  Is this so?

The other conflict scenario I see is when the user attempts to update
their web folder from both hosts at the same time, or (more likely)
wants to run a .cgi which modifies files in their volume.  I'm a bit
concerned about this one.

My initial idea to work around this possibility is a simple priority
policy.  The conflicting change owned by the greatest userid is
automatically selected to resolve the conflict.  This would allow a
user to easily manually refresh a file that a .cgi is also meanwhile
updating, so long as all the server processes clog in to a low userid.
I could possibly also give the secondary servers higher uids than the
primaries.  However, it seems to cause as many problems as it solves,
and beside that, I haven't got the first idea yet how to add an
automated resolution policy.

Am I misguided to try to hide conflicts from the users?  There's no way
I could expose them to 'cfs' and 'repair', are there any more friendly
(preferably web interface-providing) packages for examining and
manually resolving conflicts?

I guess that's all I can burden the list with so far.  I hope I
haven't used up my grace.  I realize a lot of these topics have
probably already been covered more than once.  Responses need not
cover every detail, I just want a little reassurance that what I'm
attempting isn't begging for problems.

Thanks a lot!
Mike.