Re: (provide 'nnmaildir)

[Steve Harris <sharris@primus.com>]

Simon Josefsson <simon@josefsson.org> writes:

[...]

> There are at least four solutions to the large-UIDs-from-IMAP-server
> problem (I'm not saying they are good or realistic):
> 
> . Make elisp integers hold at least 32 bit integers and re-write
>   gnus-range.el in C to make it fast.
> 
> . Implement the translation back and forth between gnus-article number
>   and imap-article number, within nnimap.

[...]

> . make Gnus accept non-integer article references.
> 
>         This might be a good thing anyway (think of using URLs to
>         reference articles), but you'd still need to do most of the
>         work in the previous point though.

Yes, I was thinking of something like putting the huge UIDs in a hash
table as strings, or building a map of

  UID (as string) => small(er), contiguous number

That is, to stop thinking of the UID as a number. I can see how that's
similar to the "translation" bullet above.

Is the problem that nnimap eventually has to send ranges of these
UIDs, and thus must understand them *as numbers* at some point?

Also, does nnimap care - so far as talking to Gnus - whether one UID
is greater than another? That is, what is the most salient property of
the UID - its uniqueness or its comparative relation to other UIDs? If
it's the former, then maybe we can try kicking more holes in the
"treat-UID-as-string" idea.

Are there other protocols that Emacs has trouble with due to its
28-bit integers? I noticed that the IMAP4 spec. requires 32 bits for
both UIDs and the UIDVALIDITY number. How does nnimap handle
UIDVALIDITY? Is it just a string compare to see if it changed?

> . change/modify your server.
> 
> Since nnmaildir seem to be coming, it might be a more realistic
> solution for you.

This one's confusing. Will nnmaildir be able to talk IMAP, or do you
mean that nnmaildir would work for a local maildir spool? Since I'm
connecting to my mail host from afar, I need IMAP.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com