161 строка
6.3 KiB
Plaintext
161 строка
6.3 KiB
Plaintext
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 separate entities, though there is still work to be done to separate
|
|
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.
|