Re: libmailcheck- backing up a step...

[Ian Campbell <ijc25 cam ac uk>]

It was a good idea to step back a bit. I would like to propose a quite top
level design for the thing, if that's OK....

The way I see the top level design is that there are 4 modules and
therefor 3 interfaces.

In order of lowest level to highest level these are:

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. 

Interface: CORBA based interface. Methods to list available mailbox's and
to create/modify them. Method to list mailbox types. Methods to attach
signals to mailboxes.

Module: libmailcheck. client library which wraps the CORBA stuff in a
GnomeMailCheck object (or maybe GnomeMailCheck is a CORBA object, I need
to look into CORBA a bit more). GnomeMailCheck has methods to query/set
settings and attach signals. this library also provides any handy
functions for the clients (see below, wrt the GUI) 

Interface: GnomeMailCheck + other functions in libmailcheck

Module: Clients, use libmailcheck to create, modify and handles on
existing GnomeMailCheck objects and to attach signals to them etc

That's my description of the system as a whole.

On Sun, 28 Feb 1999, Russell Steinthal wrote:

> * Another goal should be that we should require the minimum amount of 
> recompilation when we add new mailbox types.  What I don't know is 
> how we're going to configure mailboxes otherwise.  For some reason, 
> having the mailbox objects generating their own properties pages, as 
> Ian proposed, strikes me as a bad idea- to this point, we've had a 
> reasonable separation of GUI and backend, but this seems to be asking 
> for UI code in the "core" library.  (But perhaps that's to be 
> expected in a desktop environment...)

I agree that we should definately keep GUI stuff out of the backend (ie
lowest 2 modules) and into the client end of things. THe idea of self
generated property pages was a little off the mark, however I think that
the idea of generated property pages isn't....

The gtk-args stuff can provide enough info for a client to build a
property page for any GnomeMailCheckImpl, without knowing anything about
it (ie all the available settings and their types can be queried, this is
how glade's widget property dialog works I think). I see no real reason
why I couldn't build a text based client or configurator if I really
wanted to.. 

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

> * Along that line, I like Miguel's idea of using descriptors which 
> start with a protocol string, and then have protocol-dependent 
> information after them.  (In fact, I had thought of it 
> independently...)  That, however, just brings us back to the 
> configuration question again, since as someone pointed out, the 
> gnomecc (or whatever configurator we're using) needs to know the 
> format to build a proper descriptor.

Hopefully what I said in the previous paragraphs has swung you away from
hard-coding a protocol string towards the gtk-args way of doing things...

> * We need to handle authentication in a reasonable way.  If we end up 
> using Ian's self-generated properties pages, we can have the user 
> fill in authentication information that way.  But passwords are still 
> a problem- I suppose if we're already coupled to the UI, we can 
> pop-up a dialog box to prompt for the password and then save the 
> password in memory (but not on disk).

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

> I have notes for a third detailed interface, along the lines of the 
> first two.  But I think I might have put the cart before the horse 
> the last two times, so I wanted to see people's reactions to these 
> high-level comments before I post another version.  Are we relatively 
> in agreement about the high-level stuff?
> 
> I'd also note that while I'm happy to compile suggestions and write 
> draft interfaces, this project seems to be shifting farther and 
> farther from what I feel comfortable writing: putting together code 
> to check mailboxes was one thing, but as this becomes more and more 
> CORBA/GTK-oriented, a GTK expert (or at least non-novice) might want 
> to take the lead.  Of course, if nobody jumps forward, I will plunge 
> back into the GTK tutorial as soon as the website comes back up (are 
> there mirrors of the tutorial/docs anywhere?) and try to bone up on 
> the necessary signal, etc. stuff...

Well, I already understand a fair bit of GTK (I'm no guru though), and I
am interested in learning a little CORBA - probably between us we could
sort things out?  

Thanks.
Ian