Re: libmailcheck- backing up a step...

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.


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 with "unsubscribe"
> as the Subject.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]