Re: [fetchmail-devel] Presently running code

[Matthias A. <mat...@gm...>]

Am 12.06.2010, 00:06 Uhr, schrieb Rainer Weikusat:

> "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 :-(".

The usual there's more work than time problem that most of us share (and  
that I'd prefer to being bored all the time!).

Thank you. I will integrate the code as is for a new minor branch and see  
to publishing it shortly after the merge in Git (I plan that there be a  
series of alpha- and beta-releases).  I can't say how soon this will  
start, but I will create a Git branch for that.

That new branch will have substantially less portability hacks and will  
require somewhat recent tool chains (expecting some of the more  
sophisticated C99 features but omitting the arcane ones) and operating  
systems (Single Unix Specification v3 aka IEEE Std 1003.1-2001, 2004  
edition -- which has been superseded by v4 aka IEEE Std 1003.1-2008, but  
OS support for v4 isn't widely available yet), but is supposed to have  
little practical impact.

I currently have FreeBSD 6, 7, 8, NetBSD 5.1, Solaris 10, Ubuntu 10.04,  
Fedora 13 and openSUSE 11.2 for testing and can occasionally test compiles  
on Cygwin 1.7, Ubuntu 8.04, and Darwin (the Unix OS underneath MacOS X).

I do not care about half-baked or dying/dead non-IEEE-Std-1003 systems and  
have in fact removed support for them from the code to make it more  
readable and maintainable.

If someone wants to provide me with an SSH account (no root privileges  
required) on another operating system that is under full vendor support,  
such as DragonflyBSD, OpenBSD, AIX, HP/UX, please contact me off-list.

I think I don't care much about SCO, OpenServer, Unixware currently, but  
would take patches if they integrate cleanly and don't cause regressions  
on supported systems.

> [...]
>
>> 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.

What's wrong with that? Function pointers are a regular feature of  
standard C.

-- 
Matthias Andree