Re: Libmailcheck- take two

[Ian Campbell <ijc25 cam ac uk>]

On Sun, 28 Feb 1999, Maciej Stachowiak wrote:

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

I hope we don't end up using fetchmail (well at least not for IMAP)... The
point with IMAP is that you don't d/l the mail from the server - it is
stored and manipulated on the server.

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

Here's an idea... 

The server provides a list of known mailbox types. a call creates a new
mailbox by type name (note my previous mail for my interface ideas):

MailBox *gnome_mailbox_new_by_typename (gchar *name);

and each type of mailbox object is responsible for creating a panel of
it's own settings to be included in the apps config dialog or whatever, it
would do this by overriding the config method in the base MailBox object. 
Any app can then just call:
GtkWidget *gnome_mailbox_config(MailBox *mb);
whilst building it's config dialog....

or else the gtk-args thing should probably be used in favour of some
proprietary method, gtk-args is designed to allow apps to manipulate
unknown objects. I think it was originally desgined for GUI builders, but
would work just as well here... 

>  
> > * 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.

I beleive there is .gnome_private directory analogous to .gnome except
only readable by the user.  there are gnome_config_private_* methods to
save stuff in there. Saving a password in here should be OK? I am guessing
that password saving is (part of) the reason these methods exist.  An
option to prompt is always nice mind you. 

Bye,
Ian

> 
>  - Maciej
>