Scott, I think we talked about this before but I wanted to create a bug to track this for M6. Right now, Get New Mail is a java script function which is hard coded to get the pop service for the current server and ask it to get new mail. We need to get rid of that code and instead have the GetMsg command trickle down through RDF into the mailnews folder data source. From there, the folder (whether it be imap, pop, etc.) should ask for the appropriate protocol service and then ask it to fetch new mail. Once GetMsgs comes in through RDF there will be work at the folder level (jefft for Imap, Scott for Pop?) to implement a GetMessage command on the folder. That should be pretty lightweight though as it's just a matter of asking the protocol service to get new mail.

I'm not sure we want to go through the folder. It seems to me we want this to go through the MsgServerDataSource and have GetNewMail be an operation on the interface that represents a server rather than have each folder know how to handle this operation. Or is that incorrect?

If I understand you correctly, it's wrong for news, since if you have a newsgroup selected, get msg applies to the newsgroup, and not the newsserver. the folder has to get involved, though not neccesarily through rdf.

Urgh. Ok, I can make it go through the folder. It just seems weird to me that my sports folder would have to know about getting new mail.

It's also conceptually wrong for shared imap folders as well. I've come to accept it. In 4.x, we just overrode GetNewMail to do the right thing for all the sub-classes...

Maybe we need some kind of propagation of events so that if a folder or message can't handle an RDF command, we propagate it up to it's parent folder, until it finally reaches the server? Basically the RDF entry point would still be at the current folder, but the command would get bubbled up to the server behind the scenes and actually be executed by the server or the server's folder. RDF would never know anything actually happened.

..and this would allow News to capture the even early and download messages for the group, and IMAP could capture the event early and if the folder is a shared/public folder, just download messages for the group.

What I was planning on doing for local folders is getting that folder's server and using the same code that we're currently using. I think what your suggesting is something like this (in pseudocode): folder::GetNewMail() { server = GetServerForFolder; server->GetNewMail(); } At least that could work for local mail. Then those folders that need to do other things could.

yes, basically. I was thinking more along the lines of passing the actual RDF command to the parent, sort of a: folder->DoCommand(rdfCommand...) and inside the folder nsMsgFolder::DoCommand(rdfCommand...) { if (rdfCommand == someFolderCommand) DoSomeFolderCommand(...); else if (rdfCommand == otherFolderCommand) DoSomeOtherFolderCommand(...); ... else parent->DoCommand(rdfCommand,..); }

It's now going through RDF. You need to implement GetNewMessages in your folder.

Suresh - can you verify this in the code? Thanks.

Did a code review on this. GetMessage works in the current build. Discussed with Scott Putterman to confirm.