mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-12-05 12:05:22 +00:00
…
|
||
---|---|---|
.. | ||
src | ||
README |
README just a placeholder for now. Roland.Mainz@informatik.med.uni-giessen.de wrote: I don't know whether this is implemented or not... Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? alecf wrote: > I don't know whether this is implemented or not... > > Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? > Hmm... my gut is telling me that nobody from Netscape will be working on this....but I'm quite sure that if someone does feel like adding this functionality, many unix mail people would be very pleased... (I'm going to start calling Unix Mail "movemail" because we've called it that in past versions of the product) It's actually probably simpler than your description - we've done a fairly good job at keeping the idea of POP (as a protocol for retrieving remote mail) and Local Mail (as a way of storing mail messages locally) as seperate entities, though there is still work to be done to seperate the two. Both implementations reside in mozilla/mailnews/local though. the movemail implementation could leverage the Local Mail work, performing the same function as POP is today. Ideally, Local Mail would not be aware of any protocol specifics, so that Pop3 and movemail are both first class mail protocols. Scott or Scott could go into more specifics. If you're interested in helping us, the first thing to do would be to try to break local mail apart from POP in a way that POP is just one more pluggable mail protocol that stores mail in Local Mail....if you submit patches, I'll be more than happy to review them and check them in... > > - Does Mozilla 4.x implement local Unix mail ? Yes, but the code is VERY different than our current codebase, it's fairly simple, and wouldn't really be worth the effort of bringing it over Akkana Peck wrote: > Is there something else here that's tricky? I never understood why we > had all that movemail stuff in 4.x when we already supported Berkeley > mail files. I think one of the main reasons for this is because it's kind of good e-mail karma to move your mail OUT of /var/mail and put it in your own directory. I think this is what other unixmail clients do.... The other issue is that metadata is kept about each mailbox file - what messages are unread, the sorting order, the character set, etc... We do this normally by keeping a .msf file with the same name as the directory at the same level as this directory. This means that if I try to point my inbox at /var/mail/alecf, messenger will want to create a file /var/mail/alecf.msf It would likely be difficult to change this, because bits of our architecture depend on in ...our architecture also depends on the folder hierarchy matching a directory structure on disk...meaning that if I have, in messenger: Local Mail +- INBOX +- My Folder +- Another Folder The assumption is that INBOX is a sibling of My Folder on disk, and that Another Folder is a mailbox inside the directory My Folder.sbd (since My Folder is already a file, not a subdirectory). This means that My Folder would go into /var/mail/My Folder and Another Folder would go in /var/mail/My Folder.sbd/AnotherFolder it would be alot of overhead to try and abstract this so that each folder's location is independant of it's position in messenger's hierarchy. I think this overhead is not worth the minimal gain in capability. Alec sspitzer wrote: Alec, > > Is there something else here that's tricky? I never understood why we > > had all that movemail stuff in 4.x when we already supported Berkeley > > mail files. > > I think one of the main reasons for this is because it's kind of good e-mail karma to move your > mail OUT of /var/mail and put it in your own directory. I think this is what other unixmail > clients do.... I just looked at the movemail code from 4.x and alec is right. ns/cmd/xfe/movemail.c basically did this: lock /var/spool/mail/$USERNAME copy /var/spool/mail/$USERNAME to .netscape.mail-recovery call MSG_IncorporateFromFile() with .netscape.mail-recovery I'm leaving out the gory file locking details and the builtin vs external movemail stuff. movemail in 5.0 is like pop, but you can't leave mail on the "server", and the "server" is really your spool file. > The other issue is that metadata is kept about each mailbox file - what messages are unread, the > sorting order, the character set, etc... We do this normally by keeping a .msf file with the same > name as the directory at the same level as this directory. This means that if I try to point my > inbox at /var/mail/alecf, messenger will want to create a file /var/mail/alecf.msf > > It would likely be difficult to change this, because bits of our architecture depend on in > > ...our architecture also depends on the folder hierarchy matching a directory structure on > disk...meaning that if I have, in messenger: > > Local Mail > +- INBOX > +- My Folder > +- Another Folder > > The assumption is that INBOX is a sibling of My Folder on disk, and that Another Folder is a > mailbox inside the directory My Folder.sbd (since My Folder is already a file, not a > subdirectory). This means that My Folder would go into /var/mail/My Folder and Another Folder > would go in /var/mail/My Folder.sbd/AnotherFolder > > it would be alot of overhead to try and abstract this so that each folder's location is > independant of it's position in messenger's hierarchy. I think this overhead is not worth the > minimal gain in capability. we have ~/ImapMail, ~/Mail, ~/News, we could have ~/MoveMail Its all berkeley style mail boxes, and when we process the .netscape.mail-recovery file, it writes into ~/MoveMail/Inbox (like what pop does to ~/Mail/Inbox) in 5.0 you could have multiple imap, multiple pop, and local UNIX mail all at the same time. How about them apples? I've sanitizing the spence's old ns/cmd/xfe/movemail.c code now. I'll bring it over into the 5.0 tree, and start up a mozilla/mailnews/movemail directory. One thing: alecf and I (the UNIX people on 5.0 mail / news) will probably not have time to implement movemail for 5.0 It would be so cool if someone out there wanted to take this on for 5.0. Think about it: movemail users will love you your peers will admire you free mozilla t-shirts (I'll make sure you get some) I'm adding adding this task to http://www.mozilla.org/mailnews/jobs.html right now.