The unix mail design is pretty nice. Here's a sketch (IIUC) - mail is
delivered to port 25. This might happen in different ways - if the
machine is a well known server, this is done by SMTP clients like
Celeste, or sendmail which is an STMP forwarding program. If the machine
is a workstation (without a fixed IP), you use fetchmail - you configure
it to obtain all your mail from various sources (POP, IMAP, so forth)
and again, deliver it to the local port 25. 

So getting the mail to be local is separated from how it is handled
inside the machine (for example, by procmail calling various Mail User
Agents and telling them they have new mail).

Of course, there are lots of other ways to do things. On the down side,
I guess in this case the IMAP server is treated like just POP - you're
not using it as it was meant to be used.

Daniel

Lex Spoon <lex at cc.gatech.edu> wrote:
> 
> > Back on topic: I think I won't switch to Celeste before the file format is
> > not compatible with the standard unix stuff. Maybe there should be various
> > backends? One for the monolithic message file, one for your "each message
> > a separate file", one for "each message folder a file, nested folders are
> > directories (my pref)" - and then, IMAP support would be cool, too :)
> > 
> 
> Directly accessing files that are in foreign formats is pretty awkward. 
> It's a big design constraint, and it would put pressure on things like
> having a full index available for searching.
> 
> Directly accessing Unix mail files in particular is hard, because Squeak
> can't do Unix locking.  This is a specific reason that POP is the main
> way Celeste gets email: POP works to and  from any platform.  Could you
> instead set up your Unix files to be accessible via POP (or later, IMAP)?
> 
> Anyway, I like the idea of having multiple *sources*.  And IMAP should
> be one of them.  Doing IMAP right would require an improved index file
> format, to avoid downloading the same message multiple times.
> 
> 
> -Lex