Re: Preliminary design for libmailcheck- comments appreciated

[Havoc Pennington <hp Mcs Net>]

On Sat, 27 Feb 1999, Russell Steinthal wrote:
> 
> int  gnome_mailcheck_create_set();
> void gnome_mailcheck_register_mbox(char* fname, int set);
> void gnome_mailcheck_register_mh(char* path, int set);
> bool gnome_mailcheck_check_set(int set);
> bool gnome_mailcheck_check_all();
>

That looks nice. Minor stuff (also I agree with Mark and Maciej's
suggestions, I just got those mails while I was writing this one):

- Sets should have names, so probably there should be a get/set name 
  function for them.
- bool is not allowed in C, gboolean would be appropriate.
 
> My biggest questions are in the area of storing the information about 
> the sets/mailboxes.  Among them:
> 
> * Can I just dynamically allocate memory for data structures, say 
> linked lists?
>

Well there are two issues here. One you want to store the info in a
persistent way in a config file, using gnome-config. Two you want to load
it up when the library is actually being used. a GSList or an array is a
fine data structure for that.

> * How do I keep different users' information separate?  Does CORBA 
> affect this?
> 

gnome-config will automatically save to ~/.gnome/whatever, so that's not
an issue. A separate CORBA thingy will be started for each user. So you
can assume the library is being used by a single user.

> * While I think sets are a good idea (imagine, for example, one set 
> of user-defined "high priority" folders and another set of "other" 
> folders, or one set of "local" and another of POP3/IMAP remote 
> folders, which one might check less frequently to reduce network 
> load), how can multiple applications (in a CORBA setting, say) know 
> to use the same set ID?  Or would the user have to configure this in 
> each application?  (Not ideal...)
> 

Hmm.

Actually, I would think of things this way. The interface you give above
really shouldn't be visible to applications; it is the internals for our
little app here. Actually two apps. One app is a control panel in the
control-center for configuring mailboxes. This app saves the configuration
with gnome-config. Then a second app just performs the mail check using
the configuration;  it would schedule itself to wake up every time a
mailbox is due to be checked, and then perform the check.

Layered on top of this are all the Gnome mailcheck frontends. These can be
the mailcheck applet, GnomeEmacs, gwp, balsa - whatever applications want
to display a little icon when you have mail. Lots of apps do this.

All the "frontends" talk to the same backend; the purpose of this is to
make sure only one process has to actually check the mail. Because it can
be expensive to go across the network, etc. especially if there are lots
of mailboxes. Also it's nice to have all mailchecking apps report new mail
at the same time; I hate getting several notifications spread out over a
few minutes.

There are two purposes for CORBA:
 - communication between frontends and backend
 - a place to "register" the mailcheck backend, so only one is active
   at any given time. Also handles security issues so random people
   can't start connecting to our mail checkers.

Does all this make sense?

Anyway, the more complex interface you give above is only used by the
configuration panel and the backend. The interface for applications will
just be:
 
MailCheck backend interface:
 register(MailChecker* checker);

MailChecker (frontend)
 notify();  /* Called by backend when there is new mail */

Ideally this would be done with some kind of event-subscription system,
much like Gtk signals, but we don't have anything like that so the above 
should work fine.

Anyway, that's how I was thinking about it. (and I see I was not alone,
Maciej said the same thing.) It means there's only one mailchecker on the
system, so network/CPU is saved, and configuration is centralized. 

There are lots of common tasks that should really be CORBA-ized in this
way, that's why I think this is a cool thing to do. This kind of
integration is part of the point of Gnome. 

Havoc