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

[Alain Magloire]

> 
> >>> "Alain Magloire" <address@hidden> 26-Feb-01 9:17:40 PM >>>
> 
> >> Sun's Javamail is slow enough without getting JNI involved.
> 
> >Now this is a suprising statement : "Sun's Javamail slow".
> >I've never use it in any applications, why is it slow ?
> >Surely the bottleneck is the network, for example, downloading 
> >MEGS of messages from a POP server, then the framework 
> >being slow.
> >I do not see any rationale in such statement.
> 
> Perhaps it's rather a blase statement. I find it very frustrating to
> work with, particularly the IMAP provider but also the actual API
> implementation.
> 
> The implementation causes many unnecessary operations and much
> unnecessary caching. This slows it down, for what I'm doing anyway. 
> 
> For example, when I get an inputstream for reading a message I want
> to get the inputstream and not a stream sitting on top of a buffer.
> The base64 decoding works on thw whole buffer - it's not stream
> based!
> 
> Also when they do buffering is crazy. Sometimes the message is read
> in just to establish the size of the message! It's wierd.
>
> There are lots more examples... basically it annoys the hell out of
> me.

<speculation>

The problems (A design problem that I'm facing now) may be that they go to a
lot of trouble in bringing a consistent behaviour.  For example, as a
programmer it may be tempting to just get the header ... or the size,
they have this nice API, lets use it!

Message msg;
...
msg.getFrom();
...

This map for POP3 to the equivalent of TOP if the server supports it or
RETReiving the __entire__  email, not to throw away the information the
sensible thing is to cache.

IMAP4 allows you to get headers etc ..  But even something
simple like the number of lines or size, that are helpfull for guis
having scrollbars etc ..,  can be a problem.  Imap does not give the line
number and the only way to have an accurate number is to ... dowload the entire
message.  BodyStructure returns the lines for subparts, and the size is in
RFC822 meaning \r\n counted.

So doing something simple like:

  msg.getLineNumber() ; // Fictuous example.

Can be a killer, if the message was not dowloaded yet.

My guess is JavaMail is trying to do a lot of stuff in the background
for you.  GNU Mailutils in a sense suffers from this, but is less
agressive or more dumb.

</end speculation>

There was an excellent article on this form of "bloat" by the guys from
Sun Microsytems Labs.  Where they take as examples CORBA, RPC, NFS, and
some other distributed models.
In essence they concluded that programming models trying to make "remote
objects" similar to programming local objects are flawed ;-).

The title of the Paper:
"A Note On Distributed Computing."

Certainly worth a read.

> Some of the speed problems are architectural so we can't do anything
> about those. Where we can we've improved Javamail by reducing caching
> so that the user gets to choose how things are done.

Good idea, I will be curious to see the result, because I presume
that the working group faced the same problems.  But with different
goals and now with field experience with JavaMail the conclusions
may be different.

> I want to have as many ideas as possible about how we can improve
> Javamail without necessarily breaking it so I can take those ideas
> into the JCP and we can get Sun and everyone else to sign up to it. I
> can see Javamail changing substantially over the next couple of
> years.

Agreed. (Ack ;-).

> I appreciate you have concerns about Java... the point is that it's
> easier to write a well crafed Java program than a well crafted C
> program. It takes me less time anyway.
>
> I don't think there's a big enough issue about speed to stop one
> taking advantage of the increase in development efficiency. But that's
> just a feeling really.

OK.

> I know what you're saying but Java helps here too. Java is really
> just a layer... if I wanted world class performance from a particular
> piece of hardware I would reimplement the Java thread layer to benefit
> my application based on what the hardware could offer me.

Agreed,  the fact that the language is "thread aware" can be a big +.

> 
> I'm aiming at a totally different market. I'm aiming at large mail
> sites trying to turn them into clusters of IMAP servers.

Yep, different needs.

-- 
alain
-----
You'll have to pardon him, he's French-'Canadien' =)