On 2015-04-02 12:59, Sam Varshavchik wrote: > Anders Le Chevalier writes: > >> >>> What I just said. This is IMAP's ugly side. There's only one, >>> very specific way, to implement IMAP on the client that has >>> any reasonable chance of working with every IMAP server in >>> existence. And it's not very obvious what it should be, not >>> obvious at all. You can't rely on UIDNEXT. You can't rely on >>> half the stuff in RFC 3501, because you don't have a lot of >>> guarantees to go on. >>> >> >> What is your policy regarding Courier's implementation of IMAP? >> Support only bare minimum required features, or add new RFCs, >> even though they are optional? > > There are no formal policies written in stone. What gets done is a > combination of what I want to get done, for whatever reason, > together with anything reasonable that someone else wants to get > done, and writes a reasonable patch for it. >
Is there a reason in avoiding supporting optional features from new RFCs? I.E. supporting users who might want or need these features? ~A ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
