Re: Libmailcheck- take two

[Maciej Stachowiak <mstachow alum mit edu>]

Russell Steinthal wrote:
> 
> So, the set creation/deletion interface would look like:
> 
> MailboxSet gnome_mailcheck_create_set(void);
> void       gnome_mailcheck_delete_set(MailboxSet set);
> 
> (Those could potentially be changed to included named sets, but I'm
> not sure if I think that should be a higher level abstraction or
> included in the actual library.)
> 

Mailbox sets would be awful useless if there was no way to communicate
them between the control panel applet that sets them up, and the mail
checker that actually uses them. How do you envision this if they
have no names?

But to be honest, I think if you have a notification-based instead of
polling interface, the sets are rather useless. Each mailcheck applet
could be configured with a list of specific mailboxes you want it to
monitor. The "set" abstraction would just force you to create the
set in the capplet and then select it for the mail checker. That doesn't
seem very helpful.

> The mailbox registration interface would be used by the control
> center to add or delete specific mailboxes from sets.  To answer
> several people's questions, yes, I would envision including
> POP3/IMAP/other mailbox formats in the library, and they would each
> have their own registration function, which could potentially accept
> whatever parameters they needed (hostname, username, password, etc).
> (The suggestion to use fetchmail is intriguing, since it would remove
> a good deal of code from the library which is already written better
> than I could hope to.  But do we want to rely on it from inside of
> gnome-libs?  I don't know enough about the architecture of the rest
> of the GNOME libraries to know if that's a problem...)

Why not? Gnome-libs already relies on quite a bit of outside-developed
software. Indeed, I suspect if you asked ESR might not be averse to
creating a libfetchmail and leaving fetchmail itself as a stub binary 
that uses it.

> gboolean gnome_mailcheck_register_mbox(gchar* fname, MailboxSet set);
> gboolean gnome_mailcheck_register_mhfolder(gchar* pathname,
> MailboxSet set);
> gboolean gnome_mailcheck_register_pop3(gchar* host, gchar* user,
> gchar* pass);
> 
> We can include as many other mailbox types as people can come up
> with, just imagine similar functions.  There would also be
> corresponding unregister_* functions to remove them from sets, of
> course (omitted to save space in what is already a long message).

I think it is a bad idea to have a different function call for each
mailbox type. That means that any application that deals with mailboxes
through this interface will have to be modified at the source level
each time a new mailbox type is added. This is a bad thing. Ideally
there should be a way to query the known mailbox types, and a single
function to register a mailbox, e.g.

gnome_mailcheck_register_mailbox(ghchar *type, char *argument);

Then well-written apps won't even have to be recompiled to become
aware of new supported mailbox types. `argument' would be the
filename for a unix mail drop, a "user@host" string for a pop3
mailbox, etc.

As an alternative, the interface for querying available mailbox
types could be extended to provide the number and names of
the arguments expected for a given type. That way a genericly
written capplet could provide username and host entries for
POP or IMAP mailboxes, only a username entry for a Unix mail drop, 
etc.

One more point of confusion, but this is probably just my personal
ignorance. What mail sysem delivers mail directly to mh folders? I 
was under the impression that you had to `inc' your mail before it 
would end up in a folder.

> Internally, there would be a gnome_mailcheck_internal_check_*()
> routine for each of the mailbox types which would do the actual
> checking when needed.  Perhaps we'd need a function like
> gnome_mailcheck_set_check_interval(int seconds) in the configuration
> interface to configure that?  Even better, I think, would be if that
> were an argument to create_set() so that one could check local
> mbox/MH folders more frequently than remote POP3 mailboxes, for
> example.
> 

This whole thing should really be client-server via CORBA. All these
_internal_check routines should really be internal to the server back
end, and not exposed anywhere as APIs.

> * Almost everywhere where I used a MailboxSet above, it might be
> useful to use a list of MailboxSet's instead.  It's a tradeoff
> between having multiple calls to the functions versus dealing with
> linked lists...

A list of sets of mailboxes? Sounds a bit gratuitous.
 
> * I've ignored authentication issues, other than implying that we
> could pass as many arguments as needed to the register_pop3 function,
> etc.  Havoc seemed to imply that CORBA could be useful here, but I'm
> really unclear on this...

It won't be very useful for passing a password. But what I'd like to
see is a system where the user gets prompted for the password for his
pop or other remote mailbox when the first mail checker that wants
to access it starts up, and thereafter is not bothered with it
as long as the mailcheck server keeps running.

Saving the user's mh password in his .gnome directory of config files
is, IMO, unacceptable from a security standpoint.

 - Maciej