Bugzilla

Is there any mileage in thinking of "movemail" as protocol in it's own right?
i.e. you kind of treat "movemail" sources (ie external maildirs/mboxes) like you'd treat an external server. Configuration would be a matter of picking the maildir(s)/mbox(es) you wanted to track, and Thunderbird would slurp messages out of them into it's own folders. So there'd be a separate folder subtree in the GUI for movemail, just like how IMAP/Exchange accounts appear.
(To avoid confusion after comments 30 and 31, I'm thinking of movemail as a receive-only protocol here, not for adding messages back to mailspools).

I haven't looked at how the old movemail was implemented, but I'm very wary of it being hacked back in as special-case code.
POP3 is a bit like that at the moment: It's another protocol... but also it isn't. It piggybacks on local folders. It maintains it's own state outside the database. And there's a bunch of special handling  to complicate folder implementation and means things aren't as orthogonal as you'd like.

Doing movemail as a separate protocol has the benefit of isolating all the synchronisation policy and config and locking strategy from the folder storage code. The recent Exchange work provides a good template.

Of course, if you think of movemail always being something that just watches a single mailspool and feeds messages into an *existing* TB local folder, and don't think it shuld have it's own folder(s), then maybe thinking of it as a protocol is not the right approach...

Just wanted to throw it out there, and figure out the overall shape before we get bogged down with details.

Is there any mileage in thinking of "movemail" as protocol in it's own right?
i.e. you kind of treat "movemail" sources (ie external maildirs/mboxes) like you'd treat an external server. Configuration would be a matter of picking the maildir(s)/mbox(es) you wanted to track, and Thunderbird would slurp messages out of them into it's own folders. So there'd be a separate folder subtree in the GUI for movemail, just like how IMAP/Exchange accounts appear.
(To avoid confusion after comments 30 and 31, I'm thinking of movemail as a receive-only protocol here, not for adding messages back to mailspools).

I haven't looked at how the old movemail was implemented, but I'm very wary of it being hacked back in as special-case code.
POP3 is a bit like that at the moment: It's another protocol... but also it isn't. It piggybacks on local folders. It maintains it's own state outside the database. And there's a bunch of special handling  to complicate folder implementation and means things aren't as orthogonal as you'd like. It's messy and pops (hehe) up nasty surprises now and then.

Doing movemail as a separate protocol has the benefit of isolating all the synchronisation policy and config and locking strategy from the folder storage code. The recent Exchange work provides a good template.

Of course, if you think of movemail always being something that just watches a single mailspool and feeds messages into an *existing* TB local folder, and don't think it shuld have it's own folder(s), then maybe thinking of it as a protocol is not the right approach...

Just wanted to throw it out there, and figure out the overall shape before we get bogged down with details.