On Tue, Feb 28, 2012, CTM info <[email protected]> wrote: >However, the implementation hurdles are higher than expected. The least >painful route would be to modify the current IMAP code and break its >current behavior (downside: alienates those who use IMAP as it is), but >this *would* require very substantial work. Extending the user interface >to enable a third option besides POP3 and IMAP would be a truly >considerable project, as it would also require database work for >settings et. al.
Hi Jean Michel and everyone, thanks for your comments and suggestions. I also would not like to break the existing behavior. As you say, that alienates current users. But I'd like to follow the discussion of POP-over-IMAP a little further. Today we have a bundling of behavior and protocol, whether it be POP or IMAP or something else. My thought is to separate these and have POP behavior with IMAP protocol on the wire. So the user interface choice (POP3 or IMAP4) would actually be a choice of behavior (today it is labeled "Protocol"). The choice of on-the-wire protocol would be implicit in the specification of port number. If the port is 993 then the protocol is IMAP4+SSL; anything else is POP3. Under this approach there would be no UI changes needed, or database work for settings etc. They would remain exactly as they are today. The code for IMAP4 protocol already exists and hopefully any needed adjustment would be small. Would this approach reduce the height of the hurdle to something that could be managed? Regards.....Peter
