We implemented a webmail front end with Mail::IMAPClient and 
Mail::IMAPClient::BodyStructure without persistent connections and it seems to work 
fine with several hundred connections. We just opened up a connection to server do 
what we want then disconnect on each request. I'm sure through persistent 
objectification we could have reduced the load on the IMAP server and sped up the 
retrieval process, but what we did worked fine. 

We use qmail/maildrop/courier-imap for the mail storage see 
http://howtos.eoutfitters.net/email for destructions on how to config that setup. I 
would share the code we used for the IMAP client, but my company does sell that as a 
service so I think they might get mad if I gave away our product.

I hope this helps.

Joe

> -----Original Message-----
> From: Richard Clarke [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 9:28 AM
> To: [EMAIL PROTECTED]
> Subject: persistent Mail::ImapClient and webmail
> 
> 
> List,
>     I have the task in my hands of creating a web mail 
> application. Initial
> thoughts lead me to think I would use an external popper to 
> pop mail and
> parse it into a database for retrieval by the modperl 
> application. The only
> problem here is that I must provide the implementation of the 
> mail storage
> and folder management etc. Something I would rather not spend 
> my time on. So
> my thoughts turned to IMAP. Retrieve the mail from an IMAP 
> server. IMAP
> itself supports most mail management methods such as move 
> message, delete
> message, save draft, mark seen etc. So a few lines of perl 
> later I had a
> PerlChildInitHandler which connected to the IMAP server and saved the
> connection object. I wanted to know if people saw any 
> immediate problems
> with this solution and also if anyone could explain the following
> percularities.
> 
> If I store a single imap object in $imap, e.g.
> my $imap;
> sub connect {
>     my ($self,$centro_id) = @_;
>     print STDERR $imap,"\n";
>     unless (defined $imap) {
>         print STDERR "Connecting to IMAP for $centro_id\n";
>         $imap = Mail::IMAPClient->new( Server => 
> 'cyrus.andrew.cmu.edu',
>                                        User   => 'anonymous',
>                                        Password => '[EMAIL PROTECTED]',
>                                        );
>     }
>     return $imap;
> }
> 
> This seems to successfully save the connection object. 
> However if I attempt
> to store the object in a hash, e.g.
> my %imap_cache;
> sub connect {
>     my ($self,$centro_id) = @_;
>     print STDERR $imap,"\n";
>     unless (exists $imap_cache{$centro_id}) {
>         print STDERR "Connecting to IMAP for $centro_id\n";
>         $imap_cache{$centro_id} = Mail::IMAPClient->new( Server =>
> 'cyrus.andrew.cmu.edu',
>                                            User   => 'anonymous',
>                                            Password => '[EMAIL PROTECTED]',
>                                            );
>     }
>     return $imap_cache{$centro_id};
> }
> 
> I seem to have intermitent success in retrieving an already connected
> object. Using the first example, as far as I can tell the 
> object remains
> available flawlessley. But storing the object in the hash 
> doesn't. Am I
> making a mistake here?
> 
> Another question sprung to mind, should I think about using 
> Persistant::Base
> or some similar approach to store the IMAP objects?, or should I lean
> towards Randal's and others suggestions of having a seperate 
> (possibles SOAP
> or LWP::Daemon or even apache server in single user mode) server
> specifically designed for performing IMAP requests?
> 
> Finally, does anyone with experience in having to write 
> webmail interfaces
> see any problems with using the functionality provided by IMAP.
> 
> Richard
> 
> p.s. Yes quite obviously if I have 100 children then I'll be 
> connected to
> the IMAP server 100 times per user, hence possibly the need 
> to have a either
> a dedicated daemon connected to the IMAP server once or some 
> successfuly way
> of sharing IMAP objects between children.
> 
> 

Reply via email to