On Thu, 10 Jan 2008 13:53:36 +0100 Mildred <[EMAIL PROTECTED]> wrote:
> So, for me there should be three different (and potentially more) > programs that would manage e-mails: > - an email retriever > - an email reader > - an email writer Yup, that's (more or less) what I'd like to have some day. > And I think the basic object in the filesystem representing an email > should be a mailbox. Not a single email. Why ? Because if you use one > file per email, you have problems: > - how to name the file ? With the subject. So you'll have problem with > replies that all have the same subject Nah, there are plenty of ways to make filenames, and make sure that they are unique. e.g., use the message ID, timestamp, number them sequentially, etc. > - also, I like the threaded view of emails where replies appear below > the message they reply to. I don't think file managers can provide > that. Why not? My current mail reader uses one file per email, and provides me with a nice threaded view. > So a mailbox can contain a complete thread, or maybe all messages from > a mailing list ... you choose. And when a single email can be relevant > in itself, there is no problem having a mailbox that olly contain a > single email. Having one file per mail is more robust (a catastrophic failure during write will only affect one mail, rather than the whole mailbox), and can be much faster, especially if you use an external index. It's also much easier to manipulate your emails from the command line. The disadvantage of one-file-per-email is that you need a proper filesystem that can handle a huge number of small files. An alternative would be to store all mails in a database, but then you lose the ability to manipulate your emails using command-line tools. Essentially, the email system should be flexible enough to handle many different formats, and let the user choose. > So first, the email fetcher. It would be an application that would > only work in background, hidden in the dock or the system tray, that > would just periodically ask POP servers, IMAP, RSS feeds ... for new > mails, filter them, and put them in a mailbox defined by the > configuration (or the filters obviously). > Others applications would be able to ask the email fetcher whenever > there is any new e-mail and in which mailbox they are (maybe dBus ?) Since we're in Objective-C land here, we'll use Distributed Objects and Distributed Notifications, not dbus (although you could provide a dbus wrapper for non-GNUstep programs if you wanted). Actually, if you use inotify/dnotify/fam/gamin to just monitor the filesystem for changes, especially if we use one-file-per-mail. [...] > Well, I think a such system for reading emails would be wonderful ... > what do you think of it ? I might start soon to write applications > such as the email reader (if I find time) ... but I might as well not > (I think about it for a very long time). Yes, if only I could find time... > The only problem is what > language/toolkit I'll use. will it be Python/Gtk, Lisaac/Gtk, > Lisaac/GNUstep, Objc/GNUstep, ... Well, if you're going to ask on this list, the answer that you get will be */GNUstep. ;) -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
