On Sunday 15 May 2005 04:12, Kyle Wheeler wrote: > [snip (first paragraph)]
Thanks for the clarifications... > IMAPdir, on the other hand, supports all sorts of things, including > mixing mbox folders in with Maildir folders Ick - well I won't be worrying about that one, ever. ;-) > It also happens to be the only depot style that Binc currently supports Isn't it also true that Binc is currently the only software that supports IMAPdir? > (unsurprising, given that there are only two) that allows you to define > root-level folders. This is the feature I care most about; and, I suspect, the feature most users of IMAPdir care about. It reduces user confusion quite a bit, and makes setting up MUAs that look for Sent/Drafts/Trash at the root level loads easier (look at Thunderbird as an example - getting a typical end user to properly set up their "Copies and Folders" section of the account settings is very difficult, which isn't helped by the way Thunderbird presents the choices (1. "Sent" on <account_name> or 2. "Other Folder: " <browse browse click> "Sent" on <account_name> (inside of inbox though, which is entirely different even though the choices appear the same))). > Now, it's a valid question whether or not Binc could have a > Dovecot-style depot. If Dovecot-style Maildir's are internally > consistent, I think Binc could definitely have a "Dovecot" depot, and > probably without a whole lot of work (not that I have looked into it > much, so take that with a grain of salt). I doubt there's too much work in it, and it seems a much easier to implement solution than IMAPdir in many cases (i.e. when you have multiple IMAP/other protocol servers/scripts/mailfilter or procmail files/etc. talking to the same maildirs). I do _not_ think it needs to be an additional depot, but rather an option available when using the Maildir++ depot, and in my opinion, one that should be on by default (I'm sure others will disagree though). The difference is simply in the way the folders are structured when presented to the end user - there are no differences at the filesystem level as there are with a different depot (i.e. IMAPdir) (please correct me if my interpretation of what a "depot" entails is wrong). Change is always a pain to deal with (i.e. in the end-user filters as you mentioned), but not impossible (even to mandate to clients). I don't mind change. I would change to IMAPdir if I could, but have always run into software that won't easily work with it without custom (and experimental) patching (i.e. vpopmail). Dovecot doesn't do anything special, it just uses a plain old regular maildir++ depot without any modifications. I switched our server last weekend and the clients picked up the folder structure differences with no problems. I had to change Squirrelmail to use no prefix on the aforementioned 3 folders instead of INBOX, and changed the delimiter from / to . - nothing more was required. > Next question is if there's enough actual demand to make it worth Andreas's > time, rather than making 1.3 stable. Well here's my take. I like bincimap - I've been using it for, hmm...over 2 years now. I like dovecot - I've been using it for a few days now. I don't have any of the indexing and such enabled in dovecot, and as such, bincimap performs better (most visible from KMail for some reason, and the biggest difference is fetching all the headers from a big folder). Performance is of the utmost importance, IMHO, it's what makes qmail great and why I switched from courier to binc ages ago. Stability is, however, even *more* important. If a product isn't stable, I'll stop using it. I don't like dealing with upset clients, especially when I don't have a solution handy. E-Mail is also very important to me (and apparently most people), and any flaws or problems are intolerable. I'd rather a product be slower but do a better job (which is why I'm currently running Dovecot). Configureability comes next, so long as the product remains efficient and straightforward to configure. We all have somewhat different goals, after all. A great product fits all of them which are within it's scope (and I won't elaborate more, but I think Andreas is a great judge of what does and does not belong in an IMAP server). Aside from these general principles, it comes down to what Works For You (tm). As I said I love binc, and would like to continue using it in the future. On a personal mail server, I would almost certainly run nothing but binc. But at present, dovecot is doing a better job in some regards, and because of the folder hierarchy change, a huge amount of headache and support calls vanish (which makes my life easier). I'll address the problems in another E-mail I've been putting off to the dev list, but this feature seems more at place in this thread. Let me also clarify and say that there are plenty of things in binc that I like much more, i.e. running from daemontools with multilog logging, and so on. (Just don't tell Andreas that I like C more than C++ ;-) ). BTW, the only reason I tried out dovecot at all was because I was looking for a pop3 server for qmail that supported TLS and SSL - dovecot is both an IMAP and POP3 server in one. Cheers, -- Casey Allen Shobe | SeattleServer, Inc. [EMAIL PROTECTED] | cell 425-443-4653 http://www.seattleserver.com
