Re: libmailcheck- backing up a step...

[Ian Campbell <ijc25 cam ac uk>]

Sorry, I've been thinking a little more and you are absolutely right, you
can safely ignore the 1st half of my previous post.

GnomeMailCheckImpl is indeed an internal thing to the corba server.

Ooops,
Ian

On Mon, 1 Mar 1999, Maciej Stachowiak wrote:

> 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
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
> 
>