Forum OpenACS Development: webmail contributors
I need to write a project description for Eng. students that will be doing their thesis here at Sydney Univ. beginning in June. As we did last year I would like them to learn about web development and OACS is the best community to contribute their work.
One of the projects would be porting or integrating a webmail package into OACS.
Last year I started this thread, with interesting responses from many of you.
At that point there seemed to be an agreement about dumping the old webmail from ACS since it ws in Java and Oracle only, and with bad UI. TAlli and others proposed writing it in Python, since the language already has many of the functionalities.
I would prefer using perl and I have found perlWebmail and neomail but not tested them. They don't use a RDBMS
What does people think?
I would prefer a python based solution, as I would rather go forward learning python. There are also some other interesting python technologies out there that become interesting to the OACS and AOLserver world. There's pywx, and I'm not sure of the status of that, but holds the potential to let us efficiently do python in aolserver, and there's mailman, a very popular python based mailing list manager.
That said, I can't point you to any python based webmail packages to start from. But just think how much easier it will make to port zope modules over. Kidding.
Plus the notion that folks have to learn Tcl, SQL, Perl and Python just to read the toolkit sources is pretty gross, isn't it? It's bad enough that perl scripts wormed their way into the mix (especially given that watchdog had a bug that caused it to loop indefinitely!) but at least those were standalone scripts, not integrated into the toolkit.
Adding another language to the mix further raises the bar for entry into this world. Do we *really* need to do this?
I have other things that are being done in perl, and it would be convenient for me to do it this way, but if the community is not interested in a webmail package in perl, we would have to do it in Tcl...
with a mime rendering piece written in C as an AOLServer module. I
thought the messages should be in the filesystem using maildir format (if I
understand correctly this creates a single file per email) with selected headers
stored in the database by a script executed by the mail server.
I actually have a partially working version of the mime rendering piece using
the gmime library. It crashes when I throw a load at it which I'm not sure if
that is my fault or gmime's but I suspect mine since I'm fairly inexperienced
at C programming.
Undergraduate theses are not a continuing education or certification type of work, they are supoused to produce some type of original work.
Due to the great support of the OACS community, and the high caliber of many of its members they can do cool stuff, get help and add value, even if it is in Tcl (that I agree is not as $valuable$ as Java). The students porting calendar and wimpypoint last year were very happy with their work.
I have a draft list of projects at:
Well-paid grunts, but grunts nonetheless.
Undergrad programs should shoot for a higher level and obviously grad programs even higher.
Besides which ... is there an official, recognized PYSE that sits beside a MCSE certificate and carries equal weight?
How big is the market for Python hackers, anyway? Of all the scripting languages, I'd guess that VB Basic rules and far, far distant in second place is Perl.
Which tells you about all you need to know as to why television is so bad :)
"Most of the learning is not about a programming language its about software engineering."
<p>Thank you, thank you, thank you, thank you. That is _right_. Picking up a programming language on my own is _much_ easier than trying to pick up good software engineering on my own. Too many universites shove Java (or more recently C#) down their student's throats just because it's fashionable. IMHO Java is a terrible first language. They end up spending most of the time in their introductory CS classes dealing with the sheer complexity of the language, hence not having time to learn what's truly important.
An IMAP-based webmail package would be pretty cool.
I'm a pending grad student working on a project peripherally related to this, and Rafael pointed me to this discussion.
WING (http://users.ox.ac.uk/~mbeattie/wing/) is written in Perl and runs under mod_perl and Apache. It does IMAP and NNTP, and claims to scale well. It interfaces with an RDMBS.
The author, Malcom Beattie, is a pretty well-known Perl guy, though I can't vouch for the quality of this particular project since I haven't tried it myself yet.
I would suggest either an interface with a separate stand alone mail server, or an integrated C/Tcl module. Maybe a C/Tcl approach would allow integration of some available mail library. Dan Bernstein ( http://cr.yp.to/ ) has a library for parsing email headers, but it doesn't handle the entire message. Not fashionable, but C/C++ are still highly valued languages, of which there are a number of good examples in the AOLserver archives.
You could then have IMAP, POP3, mbox, DB, maildir modules.
I think that would give you a more flexabily webmail intregration and make changes to any part of webmail somewhat pain free.
Of course, this approach would really need to wait until after our first release.
Yes, webmail itself shouldn't be concerned with a particular protocol but should be able to talk to intermediaries that do, much as is being done with payment gateways.
I think it could reasonably be argued that IMAP already is a standard abstraction for access to mail folders, stored in a large variety of different ways.
I don't see the benefit to OACS of having its own (new, untested?) code to access every type of mail storage out there, when IMAP and the IMAP server of your choice will do that for you anyway.
Isn't creating a new OACS API for converting mail objects to/from various kinds of mail storage re-inventing the IMAP wheel?
Others still use pop and/or apop.
Also, IMAP is not completely standard, handling files and folders for Cryus IMAP, Courier-Imap, and wu-imap is different and needs to be handled in the client code.
If would be silly to have:
When you can have
login_mailbox type username password
Of if you have the user login and store the webmail config in OpenACS
you could have email_login user email_address to handle everything.
The real question is what type of webmail api's do we need and how should we store what data?
What are we going to do with mime messages? keep them in memory? Get them from the mail server, create a temp file to store it, etc.?
The underlying modules are actually the easy part. For the most part they have all been written, just need to be zapped into an underlying AOLserver/OpenACS model.
That is the part that needs discussion. As Don said (and I agree) this is something for after the first release when things have settled down, base packages have stabalized and people have time to reflect :)