Forum OpenACS Development: Response to webmail status?
i totally agree with john that the ad webmail implementation is rather broken (design) and inflexible. i haven't used phpwebmail, so i'll restrict my comments to python.
python has wonderful support for the mail protocols that comes with every python distribution in the python standard library and brings alot of additional functionality to aolserver from unittests to unicode to xml processing.
for example here's a session to check how many messages and how large my mailbox is using pop
server = poplib.POP3('mail.wm.edu')
(you can try this @ home in any python interpreter shell)
# pythons standard lib internet protocols
# python std lib internet data handling
basically the libraries take care of the protocol communication while exposing the protocol functions. its also comes with a mime library (to be updated in the standard lib by www.sf.net/projects/mimelib) and is used by one of the most widely used mailing list softwares, mailman (www.list.org)
as for mime-encoding speed. i agree its important, but i think imap serves to mitigate a large subset of mime-parsing, by preparsing entities into envelopes and message bodies. i think really think webmail should focus on supporting imap not pop, since while pop can be used in a poor man's imap mode, it really isn't designed for this and might be problematic for large boxes/messages, concurrency due to mail acct locks, security.
i've been working with python in aolserver (http://pywx.idyll.org), and i've found it to be remarkably stable. i've stress tested it, done wierd and wacky things like embedding zope in aolserver, and my dev server has been up for over a month with a stable footprint. i haven't yet done much interaction with openacs but after wrassling with the request processor i expect it will be straightforward (hopefully). i'm not sure about the php integration for aolserver, but ns_python can execute tcl commands and is pretty much a full wrapping of the aolserver c api minus some of the socket and callback functionality (python has its own socket library). the ability to execute tcl functionality means some of the session handling functionality and openacs api can be reused by a python based package.
i don't think the picture is entirely rosy though, one problem i've run into is finding a good gpl templating package for python, to date i've mainly used the ones from zope (DTML, and Zope Page Templates), but they aren't compatible with the GPL (yet). ns_python can be used from adp, but adp on a whole feels clunky compared to the relative separation of logic and presentation offered by the acs templating system.
probably the larger problem is acceptance in the openacs community. the question is are people willing to accept a package that requires the installation of the python aolserver bindings?