Closed Bug 857493 Opened 11 years ago Closed 10 years ago

add isDeferred attribute to nsIMsgIncomingServer

Categories

(MailNews Core :: Backend, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: aceman, Unassigned)

Details

I think we could add this attribute to make the server itself indicate whether it is deferred. Currently we open-code server.rootMsgFolder != server.rootFolder as the test everywhere. Are we OK with that?

We can still implement the test as server.rootMsgFolder != server.rootFolder internally at the nsIMsgIncomingServer level, and let the specific server types override it if needed.

This should not have any compatibility impact.
Currently, isDeffered looks checked by "string in serverN.deferred_to_account != null", and deferredTo account is obtained from the prefs setting.
And, in nsIMsgIncomingServer of deferredTo account, nsIMsgIncomingServer.isDeferredTo=true is set if used as deferredTo account by someone.
To refrect relation between deferredTo server and deferred servers in prefs on nsIMsgIncomingServer directly, "array of deferred servers" is needed in IncomingServer of deferredTo account, and deferredTo server is needed in IncomingServer of deferred account.
Because IncomingServer.key is always set(string of serverN), pointer to server(s) can be sting or string array intead of IncomingServer object or object array.

Because other than nsIMsgIncomingServer.isDeferredTo=true/false is not defined, I think compatibility issue can't exist. 

If such property will be implemented, "check of broken prefs by Bug 389139" will be very easy.
deferredToAccount is only an attribute of nsIPop3IncomingServer, not of the general nsIMsgIncomingServer. But I'll audit if at the various spots we actually check (via server.rootMsgFolder != server.rootFolder) for the deferrings on a non-pop3 server.
Yeah, but it looks like nsIMsgIncomingServer.isDeferredTo is equivalent to (nsIMsgIncomingServer.getCharValue("deferred_to_account") != "") so we do not need to make a whole new attribute for it until there is a really pressing needed that this workaround doesn't solve.
Assignee: acelists → nobody
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.