Single API for Email access

Jeremy Howard jh_lists at
Wed Jun 12 20:47:50 CDT 2002

You should definitely have a look at Mail::Cclient then.

Scott Penrose wrote:

> On Thursday, June 13, 2002, at 11:25 , Jeremy Howard wrote:
>> Scott Penrose wrote:
>>> <...>
>>> Does anyone have experience using these. If so, with which ones. 
>>> There is Mail::Box, but it does not seem to do IMAP and does not 
>>> give  you a list of folders etc. It is more about doing things like 
>>> MH vs MBox etc.
>>> There is also Mail::Folder, but all the work involved around that is 
>>> for local mail folders, and only supports a dot lock on the local 
>>> mail folder.
>> The problem I see is that you're forcing yourself to support the 
>> lowest common denominator of functionality this way. POP3 only 
>> supports logging in, listing ids, and getting a message (or the 'TOP' 
>> of a message). IMAP supports a complex query language for searches, 
>> multiple folders in a tree, multiple namespaces, MIME parsing and 
>> getting specific MIME parts, instant message notification, pipelined 
>> operations, etc.
> That is always a problem. The way around that I think is to emulate 
> functions where necessary.
> For example - the login and location etc should be done as a scalar 
> like that of DBI.
>     eg:
>             pop:host=someohost;user=user;passwd=somepassword
>             mh:~/Mail/
>             mbox:~/mail/
>             imap:host=someohost;user=user;passwd=somepassword
> Then lets pick a simple example like POP folders and POP writing 
> message. It can't do either. So a good starting point for those is to 
> have a method in the drivers called ->folders. It returns the list of 
> folders, in the case of pop that would be just 'inbox'. For a write IO 
> handle you get back undef.
> So like that of DBI you try and write for the middle to high ground, 
> and return undef for some unsupported methods and have some special 
> driver specific methods (eg: DBD::Excel has a list_sheets (I think)).
> If you think about how some of the webmail programs do this. There are 
> some that support both POP and IMAP servers. They do this by coping 
> with the differences all the way through their code. Why not abstract 
> that logic so that it can be reused again.
> Does this sound insane? interesting?
> Scott
> -- 
> Scott Penrose
> Welcome to the Digital Dimension
> scottp at
> Dismaimer: Contents of this mail and signature are bound to change 
> randomly. Whilst every attempt has been made to control said 
> randomness, the author wishes to remain blameless for the number of 
> eggs that damn chicken laid. Oh and I don't want to hear about 
> butterflies either.

More information about the Melbourne-pm mailing list