Single API for Email access (sounding insane huh?)

David Dick david_dick at
Wed Jun 12 21:22:27 CDT 2002

while we're on the topic of sounding insane, how far are we from writing
a completely GPLed version of MS Exchange (a la Samba)... 

cos we have Cyrus for IMAP, take your pick for SMTP, take your pick for
the DB Backend, Jabber for MSN Messenger (and everything else) and if
webDAV is the protocol for the calendaring functions, i think the gate
is beginning to swing open.... and what is a really good language for
gluing all that stuff together? :)

am i missing something else that Exchange does? it's been so long since
i was on that platform... :)

----- Original Message -----
From: Scott Penrose <scottp at>
Date: Thursday, June 13, 2002 11:34 am
Subject: Re: Single API for Email access

> 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.

NEW to mBox, receive faxes to any email address!
Find out more

More information about the Melbourne-pm mailing list