Forum OpenACS Development: webmail contributors

Posted by Rafael Calvo on 03/07/02 02:42 AM

Hi,
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?

2: Response to webmail contributors (response to 1)

Posted by Jerry Asher on 03/07/02 04:43 AM

I think it's an excellent class contribution.

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.

3: Response to webmail contributors (response to 1)

Posted by Don Baccus on 03/07/02 05:05 AM

But Python integration will *never* be efficient in the AOLserver architecture. Every thread carries (and initializes) a Tcl interpreter around with it. There's no way around it. And the Python layer has to integrate through stuff that runs through that interpreter.

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?

4: Response to webmail contributors (response to 1)

Posted by Rafael Calvo on 03/07/02 05:50 AM

I am not sure how complex it would be to do it in Tcl. I am worried that it might be a bit much for the size of projects expected.

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

5: Response to webmail contributors (response to 1)

Posted by David Walker on 03/07/02 06:04 AM

I had started looking at this type of project and the approach I liked was 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.

6: Response to webmail contributors (response to 1)

Posted by Jerry Asher on 03/07/02 06:33 AM

Don, I think you're right. What's best for the OACS would be a tcl solution. But I'm pretty sure that that is not what's best for a class of students in today's job market. Unfortunately, I think they'd be better off with Java, C##, Perl, and Python instead of Tcl. But that's for Rafael to decide.

7: Response to webmail contributors (response to 1)

Posted by Rafael Calvo on 03/07/02 06:53 AM

I think that students can learn a lot about building web apps in OACS. Most of the learning is not about a programming language its about software engineering.

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:
http://weg.ee.usyd.edu.au/people/rafa/projects/

8: Response to webmail contributors (response to 1)

Posted by Don Baccus on 03/07/02 07:28 AM

Yeah, Rafael, that's the spirit! And I think it's right-on, too (dating myself). The certification programs really exist for those who mostly don't get CS degrees or go further to grad work. They're for the grunts.

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 :)

9: Response to webmail contributors (response to 1)

Posted by C. R. Oldham on 03/07/02 03:34 PM

The "right" way to do this would be to build an OpenACS front-end to an IMAP server. Vlad Seryakov has built an AOLserver module to interface with an IMAP server, see this thread:

http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0003X9&topic_id=11&topic=OpenACS

--cro

10: Response to webmail contributors (response to 1)

Posted by Roberto Mello on 03/07/02 05:24 PM

FYI, Tcl has pretty good mail capabilities through TclLib, including pop3 and nntp support. Doesn't look like IMAP is there. <a href=http://tcl.activestate.com/software/tcllib/>http://tcl.activestate.com/software/tcllib/</a>.

"Most of the learning is not about a programming language its about software engineering."

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.

11: Response to webmail contributors (response to 1)

Posted by Don Baccus on 03/07/02 07:46 PM

Yes, IMAP, UMAP, we all want to IMAP! (that's a paraphrase of an old American kid's jingle - "I scream, you scream, we all want ice cream")

An IMAP-based webmail package would be pretty cool.

12: The WING project (response to 1)

Posted by Ken Williams on 03/08/02 12:27 AM

Hi,

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.

-Ken

13: Response to webmail contributors (response to 1)

Posted by Tom Jackson on 03/08/02 01:53 AM

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.

14: Response to webmail contributors (response to 1)

Posted by Mat Kovach on 03/08/02 02:17 AM

The best way IMHO would be to abstract things a bit, create an interface for UI<->Mail Objects that AOLserver works on (intergrated into OpenACS, use all the fun tools there) and they have message<->Mail Object modules.

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.

15: Response to webmail contributors (response to 1)

Posted by Don Baccus on 03/08/02 02:43 AM

Oh, this is all going to wait until after our first release, as far as being part of anything that gets released!

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.

16: Response to webmail contributors (response to 1)

Posted by Jonathan Marsden on 03/12/02 09:59 PM

How much abstraction is helpful, or useful?

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?

17: Response to webmail contributors (response to 1)

Posted by Mat Kovach on 03/12/02 10:10 PM

Expect that quite a few people don't use IMAP for various reasons. Some prefer havinig the webmail server directly on the mail server and access mail through the filesystem.

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:

login_imap_cyrus
login_imap_wuimapd
login_local_mbox
login_loacl_maildir

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 :)