Re: More on the new nnimap

[James Cloos <cloos@jhcloos.com>]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> The difference is that it is not an error if the group already exists,
>> except only for the new nnimap.  So how about an nnimap-request-
>> possibly-create-group?

LMI> But what you want to do is to subscribe Gnus to a group from a server,
LMI> right?  The function to do that is `gnus-subscribe-group'.

OK.  I re-did the view to create lisp which uses (gnus-subscribe-group).
They don't automatically show up in the *Group* buffer as before, so I
have to learn to do C-uAl after rather than before, but it does work.

LMI> Anyway, there is no way in the IMAP protocol to ask "what are new
LMI> mailboxes since <DATE>", so the only way Gnus has to find new groups is
LMI> to issue a LIST, right?  (Well, or LSUB, which is kinda the same thing.)
LMI> So if you have this setup, then there's no way that Gnus can get
LMI> acceptable performance if you want auto-subscription of new IMAP groups
LMI> working.

The problem with dbmail is that it first does a SELECT to grab the group
IDs requested by a LIST/LSUB, and then iterates through those to grab
the info needed to create the reply line.

Were it instead to do a single query for all of the data it needs it
would be *fast*.

As I previously wrote, I had to patch dbmail to use dense UIDs; I'll
have to do another patch to improve LIST, once I figure out the required
SQL.  (haschildren vs hasnochildren is the hard part.)

I suspect dbmail works the way it does because it was first written for
mysql; support for sqlite and postgresql was added later.

LMI> Can't you just alter your IMAP->pg thing to make LIST fast?  :-)  Gnus
LMI> just needs the mailbox names, and doesn't care about anything else.

See above.  If I can reduce it to a single select it should blaze.

>> When the mismatch occurs, one must read a number of other articles and
>> then go back to the failed one in order to see what should be there.

LMI> This is most bizarre.  Gnus requests articles from backends by issuing
LMI> first a SELECT, and then a UID FETCH.  I can't see any way for that to
LMI> fetch an article from the wrong group, unless there's something
LMI> fundamentally wrong in the sequence Gnus does these things, and I
LMI> haven't heard anything odd in the area before.

I cannot rule out a bug in dbmail or in my patch to dbmail.  I don't see
such a bug, but it might be there.

I did go back to gnus-single-article-buffer t; I don't know whether that
is relevant.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6