libmailcheck- backing up a step...

[rms39 columbia edu (Russell Steinthal)]

First, I want to thank everyone for their comments on the 
libmailcheck design- hopefully each iteration is getting closer to 
the ideal design, but feel free to tell me if I've ignored a 
suggestion or just missed it in the ever-growing pile of comments...

Rather than delve into another attempt at a detailed interface level 
description, I thought I'd back up a step and look at this at a 
slightly higher level than I did the last two times.

* We'll definitely have a CORBA MailCheck application- this seems to 
be almost universally agreed-upon as a good thing.

* I've given up on mailbox sets.  As someone pointed out (Maciej?), 
with a callback-based system, they're unnecessary, since a process 
can register callbacks for whatever individual mailboxes it is 
interested in.  And the configuration of "sets" as I described in my 
earlier message is definitely a UI/frontend function...

* The frontends (panel applets, Balsa, etc.) should be notified of 
new mail, rather than have to poll.  The various discussions about 
GTK signals, gtk-args, etc. are fairly incomprehensible to me, and 
the fact that I can't reach www.gtk.org to re-read the relevant 
portion of the tutorial isn't helping matters.  Suffice it to say, I 
think we should have whatever notification scheme is most natural for 
GNOME programmers.  That puts the ball in your court, ye who have 
been hacking this code for longer than I. :)

(I'd be inclined to let them actively poll if they need/want to, but 
I'm not sure about that...)

* Another goal should be that we should require the minimum amount of 
recompilation when we add new mailbox types.  What I don't know is 
how we're going to configure mailboxes otherwise.  For some reason, 
having the mailbox objects generating their own properties pages, as 
Ian proposed, strikes me as a bad idea- to this point, we've had a 
reasonable separation of GUI and backend, but this seems to be asking 
for UI code in the "core" library.  (But perhaps that's to be 
expected in a desktop environment...)

* Along that line, I like Miguel's idea of using descriptors which 
start with a protocol string, and then have protocol-dependent 
information after them.  (In fact, I had thought of it 
independently...)  That, however, just brings us back to the 
configuration question again, since as someone pointed out, the 
gnomecc (or whatever configurator we're using) needs to know the 
format to build a proper descriptor.

* We need to handle authentication in a reasonable way.  If we end up 
using Ian's self-generated properties pages, we can have the user 
fill in authentication information that way.  But passwords are still 
a problem- I suppose if we're already coupled to the UI, we can 
pop-up a dialog box to prompt for the password and then save the 
password in memory (but not on disk).

* IMHO, using fetchmail isn't necessary.  If we had a way to 
transparently "learn" any new mail format fetchmail learned, that 
would be great.  But since I don't think that would be feasible, and 
we're not using the "fetch" capabilities anyway, I'd be inclined to 
use the fetchmail code base as a learning tool/starting point, rather 
than calling it directly.  It's not like the code for checking for 
new mail in an MBOX file is going to change much once it's debugged, 
and I suspect fetchmail's core routines are pretty darn well-tested 
at this point.

I have notes for a third detailed interface, along the lines of the 
first two.  But I think I might have put the cart before the horse 
the last two times, so I wanted to see people's reactions to these 
high-level comments before I post another version.  Are we relatively 
in agreement about the high-level stuff?

I'd also note that while I'm happy to compile suggestions and write 
draft interfaces, this project seems to be shifting farther and 
farther from what I feel comfortable writing: putting together code 
to check mailboxes was one thing, but as this becomes more and more 
CORBA/GTK-oriented, a GTK expert (or at least non-novice) might want 
to take the lead.  Of course, if nobody jumps forward, I will plunge 
back into the GTK tutorial as soon as the website comes back up (are 
there mirrors of the tutorial/docs anywhere?) and try to bone up on 
the necessary signal, etc. stuff...

Comments are, as always, appreciated.

-Russell

-- 
Russell Steinthal
<rms39@columbia.edu>		Columbia College Class of 1999
<steintr@avnet.org>		System Administrator, AV-Network