Re: Preliminary design for libmailcheck- comments appreciated



Russell Steinthal wrote:
> 
> Those of you who have been following the thread "Re: biff utility" on
> gnome-list know that I seem to have volunteered myself to coordinate
> the writing of a mail checking library for gnome-libs, hopefully to
> be CORBA-ized by those who know more about that subject than I.
> 
> Anyway, I've done some preliminary thinking about what such a library
> might look like, and came up with the following, on which I'd
> appreciate comments.  I'll admit up front that I have been known to
> design overly-ambitious interfaces which need to be scaled down to be
> actually feasible, so feel free to bring me back to earth.

IMO you are solving the wrong problem with this API - the main problem
with mail checking (IMO) and the main reason it should be CORBA-ized is
that every app that wants to check mail needs to periodically actively
poll the files it is interested in to see if they have been updated.
Your suggested API does not cover up this problem

What apps would really like to see, I think, is an event-driven interface,
such that they will get a notification only when new mail arrives and
otherwise be able to ignore the whole mail issue.

If a central daemon does all the checking, through CORBA, this will have
the additional advantage of reducing the total number of stat()s on the
user's mailbox file, or polls to a POP server, or whatever, if for example
the user is running more than one biff-like program and/or a mail client
at the same time.

Actualy, this brings up another issue - the fact that many users do not
get mail through a unix mail drop at all. I'm not sure if your API was
meant to abstract this away or not, but POP3, IMAP4, etc mailboxes
should ideally be handled as well. Using fetchmail may be helpful here,
since it solves this problem for essentially every kind of remote mailbox.
Note also that most forms of mail boxes other than Unix mail drops will
require some kind of authentication token to access. This ought to be
reflected in the API.

 - Maciej



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