Re: [fetchmail-devel] Presently running code

[Rainer W. <rwe...@ms...>]

"Matthias Andree" <mat...@gm...> writes:

> Am 08.06.2010, 23:57 Uhr, schrieb Rainer Weikusat:
>
>> The file included below is a diff of the 'running' uid_db code against
>> the 6.3.17 fetchmail tree. I hope that it is ok in this form, because
>> I'm still in extreme 'now, we just need to deliver'-mode ...

[...]

> Is that the final submission to be expected, or do you still want to
> polish some bits of it?

This is the code which is used for the POP3-using customers of 'my'
application. Because of this, I will fix or mitigate any issues with
it which come to my attention and affect me. As always, I'm meanwhile
working on something completely different with the usual 'Yesterday!'
[emphatically!] as most wanted release date. This means the short
answer is 'Yes' and the medium-sized one would be "I can want things
all day but that doesn't mean I can actually do them :-(".

[...]

> You also mentioned Disconnected IMAP earlier, is that a project you
> are  still pursuing and/or want to submit later?
> If so, what's the status?

Using \Seen to track 'message newness' reportedly caused the
gmail-interface to no longer bring up a whole thread of communication
when using it to access a message for the first time. This was deemed
serious enough (by the powers which be) to warrant a fix and because
of this, I am running a fetchmail-variant which support DIMAP exactly
to the degree needed for this particular application. In particular,
it doesn't keep a database of actually downloaded messages but just
assumes that everything between (<last recorded uid>, <UIDNEXT>) is
interesting and anything else isn't. An additional unpleasant
workaround would be a hack intended to deal with so-called
'IMAP4rev1-servers' supporting UIDVALIDITY but not UIDNEXT (eg,
mail.amuni.com): It is assumed that the new UID space can be queried
in batches of thousands such that SEARCH UID ... never returns an empty
response except if the end of the mailbox was reached. This is
non-compliant with the IPMAP4rev1 RFC.

Independently of these technical problems, this is code I have written
with the intent that no one except myself ever looks at it and it
contains too many of my usual opinions regarding how code should or
shouldn't be written, such as using mutable function pointers as
parser state variables and things like that, that I would dare to show
it to anyone.