nnimap.el is available for way-alpha testing.

nnimap.el is available for way-alpha testing.

[visigoth]

I've got nnimap.el and imap4rev1.el up for ftp from:

ftp://olivier.pc.cs.cmu.edu/pub/

Please take a look and give me your comments.

Some notes:

* The code is pretty gross.  There are certainly some things that could
  be fixed to work better.  The intent was to get something working.

* There's at least one things (the group-parameters hack) that I don't
  think Lars likes.  (Hi Lars!)  It'll be changing in the future.

* There are a number of ways things will probably change in the future to
  improve reliability, compatibility, and performance.  I welcome any patches,
  suggestions, whatnot about the code.

* I can only guarantee the code to work with the Cyrus IMAP server right now.
  I don't have a uwash server to play with.  If anyone has a uwash server I
  can have an account on, or can write an imap-open-stream function for the
  uwash server, let me know.  I believe there's something funky about it.

* I'm gonna be asking Lars for some new optional backend calls that should
  make this implementation a lot more optimal.  (Hi Lars!)  At the moment, it's
  handicapped greatly by being pushed into the NNTP framework.  This is
  not helped by the fact that IMAP isn't optimal for large numbers of folders.


I suspect that if you -only- read mail via IMAP, everything will be
okay.  I need to optimize the hell out of this thing, because most of
our campus is going to be using IMAP to read news soon.  Gnus is quite
likely their only hope...

There's a doc file in the directory with some very rudimentary usage notes.

If you have any thoughts, questions, ideas, mail me, or reply to here
(if no one minds).

John Prevost.

Re: nnimap.el is available for way-alpha testing.

[Steinar Bang]

>>>>> visigoth@naiad.fac.cs.cmu.edu:

> I've got nnimap.el and imap4rev1.el up for ftp from:
> ftp://olivier.pc.cs.cmu.edu/pub/

> Please take a look and give me your comments.

> Some notes:
[snip!]

> * I'm gonna be asking Lars for some new optional backend calls that should
>   make this implementation a lot more optimal.  (Hi Lars!)  At the
>   moment, it's handicapped greatly by being pushed into the NNTP
>   framework.  This is not helped by the fact that IMAP isn't optimal
>   for large numbers of folders.

Hmm... what does "not optimal" entail...?

Re: nnimap.el is available for way-alpha testing.

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> visigoth@naiad.fac.cs.cmu.edu:
> [snip!]

>> * I'm gonna be asking Lars for some new optional backend calls that should
>> make this implementation a lot more optimal.  (Hi Lars!)  At the
>> moment, it's handicapped greatly by being pushed into the NNTP
>> framework.  This is not helped by the fact that IMAP isn't optimal
>> for large numbers of folders.

> Hmm... what does "not optimal" entail...?

And also: what is "large" in this context?  50 folders?  100 folders?
1000 folders?


- Steinar

Re: nnimap.el is available for way-alpha testing.

[visigoth]

Steinar Bang <sb@metis.no> writes:

> Hmm... what does "not optimal" entail...?

> And also: what is "large" in this context?  50 folders?  100 folders?
> 1000 folders?

Well--I believe our Cyrus IMAP server has in excess of 15000 groups
right now.  Obviously, the normal user doesn't subscribe to all of
them.  A cohort of mine does, however, subscribe to 200 of them.  200
-shouldn't- be that bad, but it is.

This is partially because of the mis-match between Gnus' expectations
and IMAP's brokenness.  (Gnus with nnimap is currently somewhat slow.
It's -STILL- more popular with my friends who I've convinced to try
out nnimap because it does little things like tell you how many new
messages you have, or at least indicates that you have some.)

My impression of "not optimal" is this:

Carnegie Mellon decided that IMAP was cool, and got involved with it.
For a -long- time, CMU has had a unified mail/news system, and they
wanted to keep it that way.  This brought up the idea of doing news
via IMAP.  There have been changes to the protocol to make this
easier, but not enough.

The biggest problem I see right now is that there's no way to get
information about folders in the folder-list command.  This means that
in order to get info about groups, I need to LIST them (see if they
exist) and then after that, do an EXAMINE or STATUS on each one.
STATUS is pretty fast--I switched to doing that, and the time it took
became tolerable for my friend with the 200 subs.  EXAMINE is
basically just like SELECT, except read-only (SELECT is the
folder-selection command.)  It should be able to be faster than
SELECT, but it's not.  This is that afore-mentioned up-to-two-second
delay.

The other thing is that it's impossible to notice "new" groups.  You
have to get the whole list.  THis is hairy when you have 15000 folders
on the server.

I'm planning on stirring things up on the IMAP mailing lists over this
soon.  :) I just haven't gotten a draft of any sort written, and don't
really have the time at work right now.  (I'm also not sure I want to
deal with Crispin.)

John.