Quoting Ladar Levison ([EMAIL PROTECTED]):
> I have a question that stems from my desire to integrate a Webmail
> system with my already up and running Qpopper 4.0.5 installation.
"a webmail"...
> Basically my concern is in regards to the Webmail system, and Qpopper
> cooperating nicely if both access the mbox file at the same time. I want
> to make sure someone doesn't log in through the webmail system, and
> Qpopper at the same time. Based on my reading of the source code
Can the webmail not access the data THROUGH qpopper? Which would mitigate
all the issues.
I'll also note, briefly, that
1) pop doesn't lend itself to concurrent access
2) pop wasn't intended for long term storage. The plan was to treat
the mail spool as a mail spool. Like a meat-space mailbox. go, remove
your mail from the box, dump it on the counter and deal with it.
Alterations to this scheme was where issues arise (version 7 mailboxes
don't delete from the middle very efficiently, storage, copies, etc).
= webmail basically DEMANDS long term storage of mail.
3) pop doesn't allow for FOLDERS that webmail users often want.
4) Webmail is usually SESSION oriented.
> Is this correct? I have tried scanning the /proc/locks file for active
> locks, and I can't seem to find any. Perhaps because the files are
> copied, and released so quickly.
> Now while the session is going on, qpopper uses flock() to lock the .pop
> file. That way if the session doesn't end normally, the lock still
> exists until the timeout period is over (120 seconds).
Well, AFAIR, it exists forever, qpopper will just ignore ones > timeout.
> I presently use --keep-temp-drop, so every user does have a .pop file.
> Could I code my webmail client to lock the .pop file using flock, then
> flock the Mailbox file? Would this effectively keep the two from
> accessing the files at the same time?
>
> What if I just flock'ed the mbox file? The problem I see with that
> scenario is when someone is using pop, they might have all the active
> messages in the temp file, and there would be nothing for webmail system
> to read.
And how to deliver?
> Any suggestions? Any solutions?
With no disrespect to the qpopper folk, in the case of webmail (and
I've built systems several times with LOTS of users), IMAP does
really well. The webmail program is basically an IMAP client.
IMAP allows concurrent access.
Two things touch your mail store: The delivery agent, the IMAP
server. Sendmail/whatever speak to the delivery agent, users use
IMAP (or IMAP/SSL) directly or use webmail which uses IMAP.
They get folders, concurrency,
You get something SESSION oriented.
I dealt with bad (java custom code) Webmail services that did a full
Auth/open for EVERY click on a new message. Performance sucked.
The Good webmail client had a couple parts:
- a daemon (or a couple) that threaded and spoke the the IMAP server
and managed the connections.
- The program that spoke to the webpages. This spoke to the daemon.
It was coded such that the form processing spoke to its thread
that was attached as you to the IMAP service. A simple "next
message" from the web (which is stateless, by and large) went
to the daemon. The Daemon maintained context, knew you were
on message 1142 and passed back the next message.
This is how to scale to 100k or 500k users.
I'll let you worry about intermachine connections for high scale
work.
But locking mboxes risks timeouts and fights over who "has it" and
POP just doesn't have a lot of the features that Webmail users have
come to expect (folders being the most obvious, mbox being slow being
another, lots more subtle issues).
