Re: libmailcheck- backing up a step...

[Maciej Stachowiak <mstachow alum mit edu>]

Ian Campbell wrote:
> 
> 
> Module: The actual server implementations, these are gtk objects that know
> how to query a particular mail server type. They also provide a way to
> allow themselves to be configured. Implement open() close() poll() etc
> 
> Interface: a top level gtk object - GnomeMailCheckImpl, from which server
> implementations inherit. Defines open(), close(), poll() etc. etc.
> 
> Module: CORBA server, maintains lists of active and inactive
> GnomeMailCheckImpl objects and a list of available server types (ie
> GnomeMailCheckImpl objects), provides CORBA methods to create, modify and
> get handles to them. provides a way of passing signals from the
> GnomeMailCheckImpl objects through to the CORBA clients. Together this
> module and the server implementations make up the back end.  The server
> can also load implementations of GnomeMailCheckImpl objects on the fly if
> it wants to.
> 

Why do we need to care at all about the interface between the CORBA server
and the low-level mail checking functionality? In my opinion this is entirely
an implementation issue internal to the server. It may be nice to organize it
one way or another but I don't think we should really think of it as an API
or anything. Indeed, it may be possible to implement mail checking on
some forms of mailboxes such that no active polling is necessary, instead
a file descriptor could be provided to select on (along with a timeout for
those mailbox types where active polling _is_ necessary). I can't think of
one off the top of my head, but this is one possible reason it would be bad
to overspecify the server internals prematurely.
 
> having said that, I do think building a GUI config box from gtk-args info
> might be a good candidate for a helper function in libmailcheck

Actually this sounds to me like that's something that could be useful far
more broadly than just in libmailcheck.
 
> Again there is no reason for any GUI code anywhere except in the clients.
> GnomeMailCheck objects could provide some sort of callback mechanism to
> pop up a password dialog, or it could be a part of the generated property
> pages, or both.
> 
> And again, maybe the password dialog is another candidate for a helper
> function in libmailcheck...

Well, if I am running Balsa and two mail checkers on one mailbox (say I have 
them in two panels, one of which auto-hides), I only want _one_ password
dialog to pop up per given mailbox, not three.

And I'd suggest again that a generic password dialog implementation could be
useful for a lot of other things.

 - Maciej