IMAP server (was: Re: [Savannah-hackers] gnu-socketserver)

[Nic Ferrier]

>>> "Alain Magloire" <address@hidden> 26-Feb-01 3:03:23 AM >>>

>>> I had a brief look... the mailutils IMAP server is 
>>> written in C and I'm working in Java. So that's 
>>> one difference. As far as I can see the current 
>>> effort doesn't go near fixing my problems. I also 
>>> suspect that you guys wouldn't be interested in 
>>> a Java based tool.

>What exactly is the problem you are trying to solve ?
>I presume that you are aware of JavaMail:
>http://java.sun.com/products/javamail 

I am aware of JavaMail. I'm working on a free version of the IMAP
provider for the GNU Project (I'm also the architect for a big webmail
system in the UK).


My problem, as far as it goes, is that I need an IMAP server. I don't
have one that I like so I thought I'd write one since they're not that
hard on the skin.

Here's what I'm doing:

- abstracted backend, use files as messages or files as folders
- efficient indexing based on simple directory system
- all delivery through the server, using an EXIM transport agent that
speaks IMAP
- scripting with Kawa (since the mail server will use Scheme anyway)
- shared folders implemented as shared directories and over protocol
(possibly using one of the Java NFS servers)


>> Question: With Java servers, how do you overcome 
>> the overhead of having a JVM running for every new 
>> server (one for pop3, one for imap).  It seems like it could 
>> be cost prohibitive.

>Yes, at first glance, it looks strange to try to write a daemon 
>which should be space and io efficient in Java.  Nowadays 
>JIT's are very good but still ....

I'm not writing a daemon in the inetd sense of the word. That would
be foolish in Java because of the startup time.

But Java is no slower than a C app when you come to using threads for
servers (and GCJ will make it no slower).

I'm using the GNU-SocketServer API (which I wrote for a Java
webserver called Paperclips, also a GNU app) which is a Java lib for
pooling threads over a socket listener. 

What that means is that a number of threads are instantiated and
never killed. As connactions arrive individual threads are awoken and
passed the incomming socket. It's very fast because there is no object
churn. 

If the thread pool needs to grow it can, when the threads are no
longer needed they die. The pool under idle conditions always returns
to the number of threads you configured.

I'm hoping to eventually have SocketServer do most of the things that
you can do with inetd. For example, a config option to cause
SocketServer to read the hosts.allow and hosts.deny files would be
rather cool. Automatic instantiation of servers (that it knows about)
through the inetd.conf might also be usefull.


As far as multiple servers within the JVM are concerned: I don't
intend writing a POP server but there's no reason one couldn't be
written and used with my IMAP server.

With Java one doesn't write a "server for X" but instead "an object
to be a server for X". Once you've got an object to be a "server for
X" then you instantiate the object in whatever environment you want.
If I want to instantiate a POP server object and an IMAP server object
in the same VM there's nothing to stop me. And the SocketServer API
will let me use one pool of threads for both servers if I want.


Having said all that the reason I'm using Java is because that's what
I use for nearlly everything now. To me it's just a good RAD tool.

With the IMAP server I'm not going to be using any of Java's platform
independance features, the code will be tied pretty heavily to the
GNU-Linux filesystem (since I have an abstracted backend you could
swap that out I guess).


>> Having said that I would be happy to describe the 
>> design of my server if you're interested and if you can 
>> see areas where we might co-operate I'd be happy.

>We're here for the fun and to exchange, so unless it is 
>some cie trade secrets, lets hear it.

The above should be enough for idle interest... if you're more
interested I'll tell you more.

One of the things I don't yet understand is how I'm going to deal
with shared folders not on the local system. Whatever I do will
obviously be implementation specific /8->


Nic