Complete.Org: Mailing Lists: Archives: offlineimap: July 2002:
Re: Where to from here?

Re: Where to from here?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Martijn Pieters <mj@xxxxxxxx>
Cc: offlineimap@xxxxxxxxxxxx
Subject: Re: Where to from here?
From: John Goerzen <jgoerzen@xxxxxxxxxxxx>
Date: Mon, 15 Jul 2002 13:21:58 -0500

On Sun, Jul 14, 2002 at 01:23:20PM -0400, Martijn Pieters wrote:

> I am now running offlineimap as a background process, yet it is clearly not
> intended as such. I'd like offlineimap to have a daemon mode, where status
> is logged using the to-be-included PEP 282 logging system [1]. The logging
> system would allow offlineimap to utilize syslog, the NT event log system,
> and file logs in a end-user configurable way. One could even use a
> designated mailbox for mailed exception messages (tres cool).

This should be pretty easy -- just new UIs.  I've already pondered a "cron"
UI, that would provide no input methods (throw an exception if getpass is
called), and provide only minimal output (errors/warnings only).  A syslog
could very easily be a subclass of this.

> For this to work, offlineimap wil have to log very different messages than
> the current output provides. minimal success messages (number of
> folders/messages processed), and clean exception messages. it also needs to
> be more robust in the face of server exceptions, such as connection refused
> problems.

Fortunately, the modular system already allows us to do this, as all I/O is
filtered through the UI modules, including exceptions from all threads!  So
all we need is a new UI module.

Not sure what a more robust answer to "connection refused" is, though :-)

> Once you start running offlineimap as a true dameon process, system
> administrators will want to use one process to serve all their users,
> resulting in potential ecurity problems; you'll have to think about what
> user account you'd run offlineimap as, and how mailboxes are written. It
> also may be necessary to limit the number of simultaionous connections per
> server connected to (not just the number of parallel accounts and number of
> connections per account).

This, I think, is unwise.  I don't think we should go down that road.  It
opens up so many cans of worms, and really has no advantages that I can
think of.  Think about a system-wide fetchmail and the problems that would
entail, but multiplied because in this case we not only have to worry about
each user's configuration but also about directly delivering the mail.

It's like trying to make Word a daemonized process that runs as root :-)
Doesn't make sense to me.

-- John

John Goerzen <jgoerzen@xxxxxxxxxxxx>    GPG: 0x8A1D9A1F

[Prev in Thread] Current Thread [Next in Thread]