[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 0.126, xemacs, pgnus-0.95, and really large UIDs



Michael Poole <poole@graviton.subatomic.org> writes:

> One (easy to remedy) is that LIST is hardcoded as the method to use to
> retrieve a folder list with.  On the server I am trying to use, there are
> some ten thousand or more folders, and I have to traverse the Internet at
> large to talk to it.  Listing all 10k+ folders is not something I want to
> do; neither are the subsets I want to read in any particular parts of the
> folder hierarchy -- so I cannot use the nnimap-list-pattern method to
> select those.

I think this is a Gnus config issue, tell it not to request the list
of all mailboxes on the server.

I'm pretty sure this is the default behaviour though. When do Gnus
request a complete list of mailboxes from the server for you?

The only time Gnus request a full list of mailboxes for me is when I
manually go into the *Server buffer* and select a backend. I think
it's a fair limitation if that doesn't work until we have a proper,
mailbox hirarchy aware group browse mechanism -- which was partly done
some months ago but I never groked how to do the GUI part similar to
topics in the group buffer.

> The more difficult problem is that the server likes to use the full range
> of UID values.

Ouch. Yes, it's very difficult to solve this. Gnus uses integer for
article numbers all over the place so there isn't a simple patch to
nnimap to remedy this.

> (1) (error/warning) Error in process filter:
>   (invalid-read-syntax Integer constant overflow in reader 2003395529 10)

Yes, nnimap shouldn't use `read' at all, and should gracefully handle
this problem.

> While I don't think this is going to be easy to fix, the fact that
> an out-of-range UID (and perhaps UIDVALIDITY as well) could stop me
> from reading *any* groups is fairly hampering.

Yes.  UIDVALIDITY are treated as strings so that shouldn't be a
problem.

> As a side note, the older nnimap handled this by making UIDs a cons of
> two integers, each containing part of the UID.

Sorry, I'm pretty sure Gnus doesn't handle article numbers being cons
cells. Not without extensive surgery anyway.

> I'm not terribly familiar with the nnimap code, so I don't have a patch
> myself; I'm willing to test somebody else's patches, or to try to make my
> own if someone will point me in the right general direction to fix these.

I will make nnimap handle gracefully the error you described, but the
real problem require changing the integer type in emacs to a
GMP-bignum or similar. I'm open to suggestions how to work around
this, but the few methods of doing that I can think of has too many
problems so they aren't even worth mentioning.