Re: libmailcheck- backing up a step...

[Ian Campbell <ijc25 cam ac uk>]

On Mon, 1 Mar 1999, Maciej Stachowiak wrote:

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

To be fair the actual internal implementation could be different, as long
as the client ends up with a functioning GnomeMailCheck object who really
cares, it could also be implemented using structs full of function
pointers. 

I think I might have described an abstract concept (GnomeMailCheckImpl) in
a too concrete manner, it is better to think of them as being services
that CORBA is providing a remote interface to, basically each method in
the corba object interface needs to be passed onto some method of an
object that implements it, the 2 API's are identical. The CORBA api is
hidden from the user by the GnomeMailCheck objects or library functions.
As far as the user/client is concerned the GnomeMailCheck object actually
_is_ a GnomeMailCheckImpl object, with no joins or seams (ie no visible
corba, except the library funcitons to get a GnomeMailCheck object). 

Having said all that - if we want to use signals and gtk-args the concrete
GnomeMailCheckImpl is going to need a GtkObject in it somewhere, but that
is an implementation issue....

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

The CORBA layer doesn't need to have knowledge of how and when each
GnomeMailCheckImpl object is checking for new mail. Each implementation of
a GnomaMailCheckImpl should setup it's own timer, or file descriptor and
then emit a 'signal' at the appropriate times. 

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

that's certainly true, although a more generally useful implementation
might be more complex than our needs here, it worth looking into.

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

Sorry, that is what I had in mind, I just didn't really say so. 

The first app to connect to a mailbox would cause a connection to be
opened to the server and trigger a password dialog callback if necessary. 
Then the 2nd, 3rd, 4th etc applications are just given a handle to the
same object, and the same connection is used and a password isn't needed.

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

I have my suspisions that one might exist in libgnomeui somewhere
already.

Ian.