Drat! (Re: Todo list -- POP3 retriever)

[Chris Gonnerman <chris gonnerman usa net>]

On Sun, 21 Nov 1999, you wrote:
>Anyway, onto the code end of what you've provided:
>
>1) Another argument for threading: what happens during the
>   name lookups? Blocking! The only way to get around that
>   is threading.

Drat!  I forgot that.  Otherwise my code is relatively block-free.

>2) Otherwise, the code is nice. My thought was that you 
>   could put xfer_state.dispatch to better use by having
>   little functions to do each step, then set the dispatch
>   function to the next logical step. IMHO clearer and
>   minisculely more efficient.

Actually, that code is ugly as sin... just an unfinished proof-of-concept.
The XferState->dispatch function pointer is there to support an smtp sender
function (spawned using a different queue_* function, but serviced by the same
get_data() function).  You are right that I could change the pointer to signify
changes of state; I just find the code more readable this way.  The savings in
time would be very small, and I would rather waste a gint than juggle function
pointers.

Your way would make the PS_ERROR condition code generic, though; an SMTP sender
could use the same error handler as the POP3 downloader.  Hmmm...

>3) I would favor spooling the messages to a buffer... 
>   especially if you can figure out the message's size
>   before RETR'ing it... STAT <msgnum> or some such syntax?
>   Then you could build yourself a little Message structure
>   and add it to your destination folder.

I already store that information in the XferState structure.  I personally tend
to use anonymous temp files a lot.  The only OS I work with that doesn't
handle open() and unlink() "properly" is Windoze; but if you don't like
anon-temp type files, I could just as easily store the filename in the
XferState structure for later deletion.

Remember when you write functions that suck up virtual storage to hold
messages, that some people like to mail all their friends UGACHAKA.AVI... 1.5
Mb of pure junk, expanded by MIME encoding... I always avoid using virtual
storage that lavishly.

Does Balsa do that?  Just how big a message can you reasonably expect to store
in a Message structure?