From owner-freebsd-hackers Wed Mar 29 12:04:28 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA27686 for hackers-outgoing; Wed, 29 Mar 1995 12:04:28 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA27680 for ; Wed, 29 Mar 1995 12:04:27 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA20552; Wed, 29 Mar 95 12:57:53 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503291957.AA20552@cs.weber.edu> Subject: Re: Mail... To: taob@gate.sinica.edu.tw (Brian Tao) Date: Wed, 29 Mar 95 12:57:52 MST Cc: dgy@seagull.rtd.com, freebsd-hackers@freefall.cdrom.com In-Reply-To: from "Brian Tao" at Mar 30, 95 01:36:10 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > What we need is a "mail" fstype that stores userids, mailbox > index, message counts, etc. in inode/superblock structures. Users > would be mapped to directories and individual mail messages mapped to > files within each directory. Imagine how easy something like procmail > would be to write? Or dealing with uuencoded messages? Then we could > do the same for a "news" fstype. :) Mail really wants a record oriented file system, or as you suggest, one file system object per message. I think the real issue to resolve in writing mail programs and programs to process mail one way or another otherwise is the lack of an API that is independent of the storage format. openmail/readmail/tellmail/seekmail/closemail at its simplest. There is actually a MIME user library for doing this type of thing, but it has some pretty draconian terms and is far from free. Think how easy writing something like Zmail would be with a real API for mail... 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.